PDA

View Full Version : [Multi OS] BiglyBT Extreme Mod by SB-Innovation 2.3.0.0 Beta



DigitalDJ
05.03.20, 14:31
SB-Innovation Presents

BiglyBT Extreme Mod by SB-Innovation 2.3.0.0 Beta

https://www.sb-innovation.de/attachment.php?attachmentid=3630

╔═══════════════════════════╗
Coded by:
╚═══════════════════════════╝

>>>>>> DigitalDJ & ghostfucker <<<<<<


╔═══════════════════════════╗
Credits:
╚═══════════════════════════╝

>>>>>> Butcho <<<<<<
>>>>>> Rebound <<<<<<
>>>>>> hitman <<<<<<
>>>>>> Manas <<<<<<
>>>>>> eudora <<<<<<
>>>>>> ghostfucker <<<<<<
>>>>>> anon <<<<<<
>>>>>> Instab <<<<<<
>>>>>> cloud99 <<<<<<
>>>>>> illusive <<<<<<
>>>>>> molosse <<<<<<

╔═══════════════════════════╗
Supplied by:
╚═══════════════════════════╝

>>>>>> SB-Innovation <<<<<<

╔═══════════════════════════╗
Original Mod by:
╚═══════════════════════════╝

>>>>>> Shu <<<<<<


Change Log:

+ Integrated Peer Injector 0.3 by anon
+ Perfect Spoof 2 by ghostfucker
+ uTorrent ID Generator
+ Modifiable Client Files
+ Ghostleech
+ LTEP Fixes
+ Multiple peerlist entries fixed
+ More No Report Options
+ (Fake Upload) Stop faking when swarm speed is zero
+ Upload Kicker
+ Ratio Tool
+ Synced with latest LegitBly Mod
+ (Upload Multiplier) Show as seeder
+ (SBI-Hack Torrentview) Scrollbars added
+ Fix Tracker Update Interval Divider
+ Use Swarm Peers fixed
+ Updated core to BiglyBT 2.3.0.0


BiglyBT Change Log:
BiglyBT Change Log (https://github.com/BiglySoftware/BiglyBT/blob/master/ChangeLog.txt)
Vuze Change Log (https://svn.vuze.com/public/client/trunk/azureus2/src/ChangeLog.txt)

Installation:

Windows

1. Download and install the latest OpenJDK Java. It must be Java version 13 or higher. (JDK GA Release (http://jdk.java.net/13/)).
2. Download and install the latest non-beta BiglyBT release (BiglyBT - Download (https://www.biglybt.com/download/)).
3. BACK UP YOUR TORRENT LIST! IT IS LIKELY YOU WILL LOSE IT!
4. Extract the hack files using 7-Zip (7-Zip Download (http://www.7-zip.org/download.html)) or equivalent to %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT) and overwrite ALL files.
5. Delete the "jre" folder in %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT).
6. Open the OpenJDK archive downloaded in step 1 and extract the "jdk-XX" folder to the BiglyBT folder %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT).
7. Rename the extracted "jdk-XX" folder to "jre".
8. Run Notepad as Administrator and open %PROGRAMFILES%\BiglyBT\BiglyBT.exe.vmoptions (C:\Program Files\BiglyBT\BiglyBT.exe.vmoptions), append the following line:
NOTE: If you want to run BiglyBT-console.exe perform step 8 but instead create file "BiglyBT-console.exe.vmoptions"


--patch-module=java.base=ghostfucker_utils.jar
--add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED

9. Run BiglyBT and Enjoy!


macOS
1. Download and install the latest Java. It must be Java version 9 or higher. (JDK GA Release (http://jdk.java.net/13/)). Note the path to the OpenJDK archive downloaded. You will need it for step 5.
2. Download and install the latest non-beta BiglyBT release (BiglyBT - Download (https://www.biglybt.com/download/)).
3. BACK UP YOUR TORRENT LIST! IT IS LIKELY YOU WILL LOSE IT!
4. Extract the hack files within the ZIP file to /Applications/BiglyBT/.biglybt and overwrite ALL files.

NOTE: To see the folder in Finder, you may need to perform the following steps:
4a. Open Terminal
4b. Run the following command:


defaults write com.apple.finder AppleShowAllFiles YES

4c. Hold the "Option/Alt" key, then right click on the Finder icon in the dock and click Relaunch
4d. Once you have copied the files, you can revert to hiding folders with:


defaults write com.apple.finder AppleShowAllFiles NO


5. Open up a Terminal and run the following commands. NOTE: You need to replace "PATH_TO_OPENJDK_ARCHIVE" in the first command to the path to the OpenJDK archive from step 1.


OPENJDK_ARCHIVE="PATH_TO_OPENJDK_ARCHIVE"
sudo rm -r "/Applications/BiglyBT/.install4j/jre.bundle"
sudo tar -xzf "$OPENJDK_ARCHIVE" -C "/Applications/BiglyBT/.install4j/"
sudo mv "/Applications/BiglyBT/.install4j/jdk-"* "/Applications/BiglyBT/.install4j/jre.bundle"
echo -e "\n--patch-module=java.base=ghostfucker_utils.jar" | sudo tee -a "/Applications/BiglyBT/.biglybt/java.vmoptions"
echo "--add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED" | sudo tee -a "/Applications/BiglyBT/.biglybt/java.vmoptions"

6. Run BiglyBT and Enjoy!

Linux
NOTE: Based on Ubuntu 19.10
1. Install the latest OpenJDK and libjna package from your distro's package repository. On Ubuntu 19.10 this is openjdk-13-jre and libjna-java.
NOTE: Some distros do not have an OpenJDK of version 9 or greater available. In which case, you will need to download and extract the tar.gz package supplied by OpenJDK (JDK GA Release (http://jdk.java.net/13/)).


sudo apt install openjdk-13-jre libjna-java

2. Download the latest non-beta BiglyBT release and make it executable (BiglyBT - Download (https://www.biglybt.com/download/)).


wget https://files.biglybt.com/installer/BiglyBT_Installer.sh
chmod +x BiglyBT_Installer.sh

3. BACK UP YOUR TORRENT LIST! IT IS LIKELY YOU WILL LOSE IT!
4. Run the installer, specifying app_java_home variable to your JRE folder. On Ubuntu, this is: /usr/lib/jvm/java-13-openjdk-amd64/


app_java_home="/usr/lib/jvm/java-13-openjdk-amd64/" ./BiglyBT_Installer.sh

5. Extract the hack files within the ZIP file to "~/biglybt" (/home/<username>/biglybt)


unzip -o BiglyBT_*.zip -d "~/biglybt"

6. Append the following VM options:


echo "--patch-module=java.base=ghostfucker_utils.jar" >> "~/.biglybt/java.vmoptions"
echo "--add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED" >> "~/.biglybt/java.vmoptions"

7. Run BiglyBT and Enjoy!

Troubleshooting:
Before posting problems please make sure:
1. You have updated Java in the "jre" folder to the latest version (must be Java 9 or higher) (JDK GA Release (http://jdk.java.net/13/)]).
2. You have uninstalled BiglyBT using the uninstaller.
3. You have removed the BiglyBT Application folder:


C:\Program Files\BiglyBT (Windows x64)
C:\Program Files (x86)\BiglyBT (Windows x86)
/Applications/BiglyBT (macOS)
~/biglybt / /home/<username>/biglybt (Linux)

4. You have removed the BiglyBT Settings folder:
NOTE: THIS WILL RESET ALL BIGLYBT SETTINGS AND TORRENT LISTS


%APPDATA%\BiglyBT / C:\Documents and Settings\<username>\Application Data\BiglyBT (Windows XP - Application Data may be Hidden)
%APPDATA%\BiglyBT / C:\Users\<username>\AppData\Roaming\BiglyBT (Windows Vista - AppData may be Hidden)
/Users/<username>/Library/Application Support/BiglyBT (macOS)
~/.biglybt / /home/<username>/.biglybt (Linux)

5. Reinstalled BiglyBT using the package from BiglyBT - Download (https://www.biglybt.com/download/).
6. Re-applied the hack by following the installation instructions above.

Portable Mode:
Portable mode is now built into BiglyBT / Vuze. See wiki article: Portable Vuze (https://wiki.vuze.com/w/Portable_Vuze).



Enjoy!

salsa12
07.03.20, 08:26
Thanks for share!. But i want to report bug, there is "when downloaded completed delete torrent in seeding list" funtion not working can you fix it pls?

simexi
07.03.20, 09:30
Yep. This does not work.

--->HDBD<---
07.03.20, 10:08
Noch ein mal zu erinnerung Perfect spoof funktioniert nicht auf hdbits und bithdtv wenn jemand ein lösung hat bitte her damit
Installiert ist BiglyBT 2.3.0.0 und Java 13.0.2

One more reminder Perfect spoof does not work on hdbits and bithdtv if someone has a solution please bring it here
Installed is BiglyBT 2.3.0.0 and Java 13.0.2
20310

JP2020
07.03.20, 11:21
Noch ein mal zu erinnerung Perfect spoof funktioniert nicht auf hdbits und bithdtv wenn jemand ein lösung hat bitte her damit
Installiert ist BiglyBT 2.3.0.0 und Java 13.0.2

One more reminder Perfect spoof does not work on hdbits and bithdtv if someone has a solution please bring it here
Installed is BiglyBT 2.3.0.0 and Java 13.0.2
20310

More details on the issue you see?

--->HDBD<---
07.03.20, 12:44
What other details do you need

JP2020
07.03.20, 13:49
Details of the spoof you are using for starters?
Spoof client, udp/tcp,

Have you been banned or is it an auto tracker message you are getting?
If a tracker message the precise message - although that doen't necessarily mean it isn't something else thats resulting in the message



What would help for starters with the client/os etc you are attempting to run is showing what you are actually reporting to the tracker/other clients
No need for great technicality for that - just run two clients on the same torrent and look at what your spoof one is actually reporting to the other client

--->HDBD<---
07.03.20, 16:17
No i am not banned

JP2020
07.03.20, 21:20
I see
I've just checked it myself, and despite all the claims of the BBT program - its reporting its real id

spoof is NOT working for either op or me
tested with 2 * qB clients and a transmission client - in ALL cases BBT reports actual bbt client (2.2.0.2 in my case) to trackers
- despite all signals in BBT saying its running the spoof.

BBT seems to think its running the spoof - its NOT

OUR ARSES ARE HANGING OUT

This was NOT the case in my old vuse client spoofing

---------- Post Merged at 21:20 ---------- Previous Post was at 20:35 ----------

My BBT install
BBT reports duff clients and disables spoof - and gives warning - which I have set
Reports 'good' clients as running in bottom left of panel

The spoofs are quite clearly NOT actually sending the spoof id info.

@anon
Dont believe this is anything to do with tests I am running and as op has clearly seen this for ages ....



My contents:
azureus.spoof.boolean=False
azureus.spoof.spoofbiglybt=True
azureus.spoof.value=2.2.0.2

DigitalDJ
08.03.20, 07:52
I've deleted the attachment. Will have to look into this over a few days.

JP2020
08.03.20, 11:06
Thanks @DigitalDJ
This isn't limited to the named trackers, I've tried it on others.
It generally isn't sending the spoof info

Not checked to see if version spoof changes the version reported.

Let me know if you need me to check anything.

---------- Post Merged at 10:55 ---------- Previous Post was at 10:31 ----------


What other details do you need


Do you know which version if any it last worked?
or at least earlier versions where you saw it didn't work?
ie did it work in 1.9?


It would seem NOT to be working in 2.2 or 2.3

I know the spoofing worked fine in older version of 5.x vuze.




info might help finding the issue...


note
Don't rely on Bigly saying it was/is working to report it as working folks ..
ACTUAL Check at least until we know its sorted.
and report any issues you see.


Thanks again @ --->HDBD<---

---------- Post Merged at 11:06 ---------- Previous Post was at 10:55 ----------

What we need perhaps is a very limited tracker that just reports back in error message the client info when a client connects ..
(maybe dumps the peerid/header back in error message?)

--->HDBD<---
08.03.20, 11:57
I don't know exactly but until last vuze version everything worked

with same settings works on hdcenter.cc and bittorrentfiles.me BiglyBT 2.3.0.0 and Java 13.0.2
20313

DigitalDJ
08.03.20, 14:18
Sorry, can you specify the exact version that you think it last worked?

--->HDBD<---
08.03.20, 15:13
Vuze Extreme Mod by SB-Innovation 5.7.5.0
http://www.sb-innovation.de/showthread.php?33148-Vuze-Extreme-Mod-by-SB-Innovation-5-7-5-0

what does this plugin client identification mean you can't disable it
20314

anon
08.03.20, 16:37
I saw all the bug reports on the previous thread and this one, but didn't reply because I had nothing to say besides "it works for me". Needless to say, we tested the mod before releasing these new versions and none of these issues came up at the time. There has to be something wrong if features aren't working for you after following the installation procedure, though, so... let's go over this point by point.

My setup at the moment: Windows 7 x64, Java 13 (openjdk-13.0.2_windows-x64_bin), BiglyBT Extreme Mod 2.3.0.0. Custom portable setup with no "jre" folder, Java is in my %PATH% and I use a script to launch the mod. Note that I did not do a clean install, I'm using the same settings as in 1.9.0.0 (with the exception of uninstalling Peer Injector before the upgrade, since that's integrated in the mod now) with no problems besides having lost the torrent list.

List of reported bugs thus far:

sun.net.util.IPAddressUtil.checkAuthority(Ljava/net/URL)Ljava/lang/String error: this is caused by not having the latest Java runtime. As I recall, it also happened with the very first BBTEM release for those who ran Java 8. Upgrade and it gets fixed.
Losing the torrent list: unfortunately, this is normal and the first post warns you in advance. As I recall, it happens when configuration parameters are added or changed in the mod. Since the backup feature in BiglyBT is just a fancy interface for saving and restoring some .config files and the "active" directory, you shouldn't expect any special results from using that vs. doing the same thing manually. In the past the torrent list was wiped with nearly every new version, so I'm sort of used to it myself.
Perfect Spoof not working: I can't reproduce this, it works fine for me. I have mine set to uTorrent 3.5.5 and that's what gets reported, verified with Wireshark. My BiglyBTSpoof.properties is untouched from the default, and the official Client Identification plugin (which I thought would be removed in version 2?) is disabled.
"When download is completed... stop the torrent" not working: it works for me, I just tested it. (If you have enabled the setting to hash check torrents after they're completed, the feature works too well and stops and removes torrents before the check finishes, but that's a known issue, see 350015 onwards.)
Password feature in interface tab: this is not a mod feature, so I haven't checked it.

JP2020
08.03.20, 19:56
I don't know exactly but until last vuze version everything worked

with same settings works on hdcenter.cc and bittorrentfiles.me BiglyBT 2.3.0.0 and Java 13.0.2
20313


Not sure if its relevant - but both the trackers I tried it on are (old) http trackers


It may be the way DigitalDJ and anon are running BBT which means that theirs work, both probably use custom runs ...


It may also be that I had issues with the install, and still can't get my old Vuze version working properly (not uninstalled BBT yet) although I've got an older version to the start up and basic working but when i try to select option to spoof I get 'not until VEM finished loading that has been reported by other users.
But at least I can see the old stuffer to remind me what it looked like - with the timing setting bar.


fkn original coding of BBT seems to be a poor example with direct addressing to paths and allsorts, hence the half-baked portable mode' ... and having to piss about with java
Amazed you guys managed to patch it. {applause}


These issues may also be caused by crap left in our OS's that the BBT code doesn't like





Oh and I am certain it is reporting the actual BBT not some leftover whatevere, as I updated the tracker with a gen client - it updated to that, updated tracker with BBT - it flipped back to BBT 2.2 despite BBT claiming it was running a spoof client

All the time BBT swearing blind it was running the spoof in its settings.

anon
09.03.20, 07:13
Not sure if its relevant - but both the trackers I tried it on are (old) http trackers

I tested it with HTTP trackers too, it's easier to capture the traffic that way. Java uses its own certificate store, and installing a custom root CA there to MITM encrypted traffic is a small odyssey.


It may be the way DigitalDJ and anon are running BBT which means that theirs work, both probably use custom runs ...

We're looking into it. I'm willing to share my entire profile (Java 13 + BiglyBT 2.3.0.0 + corresponding Extreme Mod + configuration folder + launch script) to see if it works for you too, but that may have to wait a few days.

DigitalDJ
09.03.20, 07:22
Just so we're all on the same page. For those having issues, can you:

- Screenshot the Help > About window
- Screenshot Extreme Mod Options Window
- Is the torrent tracker HTTP? HTTPS?
- Was the torrent added after installing 2.3.0.0?

JP2020
10.03.20, 19:40
My tests were HTTP not HTTPS - so yours OK - mine not
More than happy to try your install see if it fixes the issue - and I lean toward some some issue with the Java install


Java installs (note I installed 32 bit yesterday to see if it made older 32 bit azureus work again - it didn't. 64 bit was installed prior to BBT)

Zulu JDK 13.29 (13.0.2) 64 bit - Issues seen prior to extra 32 bit instal
Zulu JDK 11.37 (11.0.6) 32 bit - yesterday in addition to above to see if it sorted old/new azureus install issues - nope



About (done just now):

Java 13.0.2 (64 bit)
Oracle Corporation
c:\program files\biglybt\jre

SWT v4922r17, win32, zoom=100, dpi=120
Windows 7 v6.1, amd64 (64 bit)
B2.2.0.2-00/4 az3
Java 13.0.2 (64 bit)
Oracle Corporation
c:\program files\biglybt\jre




I'll look further into these suggestions although it might be tomorrow



What does occur to me is:

* We are all using the same few bbt installs
* We are all using the same few patches
* We are all using largely the same spoof clients


I seem to have seen that the base installs leave crap all over windows registry


I tried installing 64bit BBT with a working 32 bit old Azureus and it stopped that version working, and a fresh install of a later 5.7.x does not work as yet, although i didn't uninstall my prior working 5.3x Az/Vuze
Unistalling the 5.7 version removed the *uninstall for the older version, but left crap all over the registry


but : Java

We install JDK PLUS copy/rename the JDK extract into the Bigly dir?

HUH?
Why do we need the JDK base install rather than just the jre in the bigly path (or just the base install - remember I know little/NowT about Java)

I think sorting out any Java install issues is perhaps priority unless someone knows better




Could easily be wrong, but I have a sense the issues aren't primarily with the program or patch, but are with the java installs and/or crap in the windows setup.


I may run a reg clean of all Bigly/Vuze/Azureus entries and a fresh install after first test of a full clean install, but it would help if i knew a few ins/out of the java install(s) requirements
- because if it is something with the java install, then all else is pointless..


---------- Post Merged at 11:01 ---------- Previous Post was at 10:42 ----------

basics for starters lol

Why full jdk rather than jre?

Why install java PLUS copy to BBT jre dir?

---------- Post Merged at 16:16 ---------- Previous Post was at 11:01 ----------

in the meantime, now I'm looking closer, why does BBT try to connect to amazon aws 34.237.37.24 port 443 (and a couple of other amazon aws connection attempts on other ports) on startup with no active torrents ??

---------- Post Merged at 18:44 ---------- Previous Post was at 16:16 ----------


I don't know exactly but until last vuze version everything worked

with same settings works on hdcenter.cc and bittorrentfiles.me BiglyBT 2.3.0.0 and Java 13.0.2
20313


are you sure its reporting the spoof ids rather than reporting biglybt?
or just assuming all ok as there seems to be no problems?

---------- Post Merged on 10.03.20 at 00:21 ---------- Previous Post was on 09.03.20 at 18:44 ----------

Ok
Same issue with install of 5.7.5.0

Needed to uninstall and downgrade the 32 bit JRE (not used JDK this time) to get it to install and run to the level of
1, It Installs
2. Options comes up
3 seems to run except for the spoof issue


Java 1.8.0_242 (64 bit)
Azul Systems, Inc.
c:\program files (x86)\zulu\zulu-8-jre

SWT v4716, win32
Windows 7 v6.1, x86
V5.7.5.0/4 az3



Reports as 5.7.5.0 to tracker despite claiming to be running transmission spoof.

Scratching my head a bit now.

So front end stuff is working
setting the spoof seems to work,
trying to use one with script error results in error message and disabled spoof

Clearly the Backend actual send the stuff isn't.


My working version was ancient 5.3 which I will try to get around to installing and trying tomorrow


Bigly 64 bit + vuse 32 bit now both running with the 13 64 java and 8 32 java.

(+cleaned some Azureus crap out of registry - but nothing significant)

---------- Post Merged at 09:52 ---------- Previous Post was at 00:21 ----------

Just an addition test with perfect spoof enabled or disabled

azureus.spoof.boolean=False
azureus.spoof.spoofbiglybt=(True or False)
azureus.spoof.value=(2.2.0.2 or 2.2.0.0)

Still reports the actual biglybt 2.2.0.2






Makes no difference
Still reports Biglybt 2.2.0.2

Setting:

Perfect spoof unticked
azureus.spoof.spoofbiglybt=True
azureus.spoof.value=2.2.0.0

Says in options-Extreme mod

Activated ? false version 2.2.0.0

although I do realise this may have been disabled in core - remember reading something about that here.

---------- Post Merged at 19:40 ---------- Previous Post was at 09:52 ----------

Its would seem to be nothing to do with the Bigly or vuze versions and all to do with the Java/install

Just what, I don't know yet

JP2020
11.03.20, 09:00
I'm not certain by any means, but I have some reason to believe that its the bigly/vuse clientid feature thats causing the issues.

That the spoof is updating the info as it should, then BBT may be overwriting it with the real bigly peerid



Having horrendous problems now with the various java/vuse installs removes etc I have done.
Although seems to be largely working apart from the spoof peerid - geting issues with magnet opens and allsorts of erratic issues I didn't have before - all seem to be java related, likely to be the crap that BBT/Vuse leaves lying about in the reg etc after installs uninstalls.

More than half wish I'd never updated. Spent bloody hours and hours on this, and no doubt it'll be a switch or two setting somewhere along with java version incompatibilities/irregularities.

DigitalDJ
11.03.20, 13:53
There's nothing stored in the registry. Literally just %APPDATA%\Roaming\BiglyBT and %PROGRAMFILES%\BiglyBT.

Just uninstall all Java, and extract the OpenJDK package into the jre folder, in the BiglyBT folder. Nothing more. Nothing else will "conflict".

Spidtest
11.03.20, 14:07
Works for me.

MacOS + Java 13

JP2020
11.03.20, 16:17
There's nothing stored in the registry. Literally just %APPDATA%\Roaming\BiglyBT and %PROGRAMFILES%\BiglyBT.

Just uninstall all Java, and extract the OpenJDK package into the jre folder, in the BiglyBT folder. Nothing more. Nothing else will "conflict".

Strange that there were so many entries then?
With vuse, azureus and biglybt referred, and not just magnet associations.


So you are saying you dont need to:
1. Download and install the latest OpenJDK Java. It must be Java version 13 or higher. (JDK GA Release).


... Thought I had tried that and it wouldn't work without java 'installed'

In fact - just uninstalled all javas and BBT wont start - it still has the jre folder.


Uninstalling all the various javas has already broken other things.

---------- Post Merged at 16:17 ---------- Previous Post was at 16:17 ----------


Works for me.

MacOS + Java 13

I thought that too until I looked closer.


Interesting thing is I KNOW (absolutely certain) the older vuze was working before my first install of BBT

Now NONE send the spoof peer id although they show as they are spoofing
and they do SEEM to send things like the staticNumwant Ok
not certain - but the trackers do seem return the requested amount - I checked.

I am using a vpn, but as far as I am aware, that shouldn't make any difference other than connect-ability.

Spidtest
11.03.20, 21:10
I thought that too until I looked closer.


Interesting thing is I KNOW (absolutely certain) the older vuze was working before my first install of BBT

Now NONE send the spoof peer id although they show as they are spoofing
and they do SEEM to send things like the staticNumwant Ok
not certain - but the trackers do seem return the requested amount - I checked.

I am using a vpn, but as far as I am aware, that shouldn't make any difference other than connect-ability.

No. It works. I'm also behind a VPN.

User-Agent: qBittorrent/4.2.1
Accept-Encoding: gzip
Connection: close

Captured straight from wireshark

Also checked peerlist and I see qBittorrent 4.2.1

JP2020
12.03.20, 10:20
Installation:

Windows
1. Download and install the latest OpenJDK Java. It must be Java version 13 or higher. (JDK GA Release).

Now as this points to what is apparently a zip with some sort of java aficionado stuff in it with no install, msi or even how to install with it :-/
(search through further pages and you get to some sort of reference se install, but by that stage you seem nowhere near where you were pointed .. at a GA install)
If you do download it it seems it meets the 'extract the contents' criteria in part 4 - but thats 3 steps away ...

SO, I searched for some installs and after a first install which did not go well after searching around the linked suggestion and trying (which may have been what screwed things up), I found these: (also zulu java installs which I also tried a number of times)

https://adoptopenjdk.net/

so seemingly wanting openjdk 13.x for windows 64 bit I went:
https://adoptopenjdk.net/releases.html?variant=openjdk13&jvmVariant=hotspot

Which give installs for a number of O/S's and the zip files which SEEM to meet the criteria of parts one and 4 of the install process.

Don't know why us end users need the JDK rather than the JRE, but thats what it says so:
Selected and installed x64 13. jdk and downloaded the zip to enable extract


Was anything there wrong?



and if thats right, on the install should I set the optional but excluded by default :
set Java_home variable + javasoft (oracle) registry keys
options in the install?


Biglybt\jre has been added to the windows path.

---------- Post Merged on 12.03.20 at 00:50 ---------- Previous Post was on 11.03.20 at 21:12 ----------

Ok
I've fixed it - but introduced a different error, then broke it again

Its all about what version of 'extracted stuff renamed to jre' is in the biglybt\jre folder and perhaps also whats is and perhaps isn't in the path variable and a number of java/bigly/vem related system variables.



Using the 64 bit 13 hotspot jdk msi as a base install + copying the code extracted from the equivalent jdk zip fixes the peerid issue, but introduces problems with opening magnets etc - generates errors (damaged jvm in biglybt\jre fix or set some e4j something or other) - but you can paste the magnet in and it works.

MOST importantly - it sent the spoofed ltep/peerid



Extracting the actual jre code from the equivalent version zip and putting actual jre in the biglybt\jre folder reintroduces the silent but deadly unspoofed peerid issue - magnets open in prog fine and all else seems to work.

---------- Post Merged at 10:20 ---------- Previous Post was at 00:50 ----------


Installation:

Windows
1. Download and install the latest OpenJDK Java. It must be Java version 13 or higher. (JDK GA Release).

Now as this points to what is apparently a zip with some sort of java aficionado stuff in it with no install, msi or even how to install with it :-/
(search through further pages and you get to some sort of reference se install, but by that stage you seem nowhere near where you were pointed .. at a GA install)



So, It would be much appreciated if some kind person with java knowledge, or just experience of successfully deciphering that part 1 for a windows install and extract to biglybt\jre -

please tell me what I need to do to install the stuff in that GA zip at the link location (or what actually is needed), and confirm that is the extracted stuff that needs to go into the biglybt\jre folder

and also hopefully what needs adding to windows path, and what windows environment variables need to be set/unset.

- and I'll test it and confirm that asses are not hanging out

(be assured that I HAVE confirmed that asses are hanging out in a NUMBER of setups I have tried, whatever bigly VEM may seem to be stating. I have also confirmed that it does spoof peer_ids correctly at least in some - no doubts whatsoever in this)

Thank you.

DigitalDJ
12.03.20, 13:05
Installation IS extracting to zip to the BiglyBT/jre folder. Nothing more. No variables need to be set.

JP2020
13.03.20, 10:10
Not tested yet but if so, can I suggest you change the first line of the instruction to just

1. Download the latest OpenJDK Java GA zip (link to page) ready to extract some files later in the process.

---------- Post Merged at 15:12 ---------- Previous Post was at 14:36 ----------

Quick test

fresh download linked 'openjdk-13.0.2_windows-x64_bin.zip' and extracted files

Shut down BiglyBT 2.3.0.0 (yep trying later one - same issues)

deleted hotspot jdk extract \jre in biglybt folder

Copied extracted files from openjdk-13.0.2_windows-x64_bin.zip to biglybt\ folder and renamed jdk-13.0.2 to jre


restarted BBT
Select qbittorent spoof client from here 4.1.3 with encryption
restarted BBT - says spoofing that client

- queued torrent

biglyBT 2.3.0.0 pops straight up in tracker as client
BiglyBT says its spoofing qb

---------- Post Merged at 18:50 ---------- Previous Post was at 15:12 ----------

and in the meantime
I've removed the path and system variables set up by various javas including the hotspot java

Now BBT wont even start - as i've stated previously
2 messages:


The procedure entry point ucrtbase.terminate could not be
located in the dynamic link library#api-ms-win-crt-runtime-l1-0.dll


The JVM found at c:\programfiles\biglyBT\jre is damaged
Please reinstall or define EXE4J_JAVA_HOME
to point to an installed 64-bit JDK or JRE



So downloaded the se 13 from the link page, extracted that, renamed to jre and deleted the existing biglybt\jre (the GA linked) with that
BBT wont start, same messages.

---------- Post Merged at 20:37 ---------- Previous Post was at 18:50 ----------

***


on the other hand - deleting the jre in the biglybt folder and setting the path to the hotspot jdk install
- bbt starts - and with the VEM options




Which seems to demonstrate precisely the opposite of what you have said. It needs an installed jdk (or jre) and the extract of the files might do nothing at all and without the path to the installed jdk it simply doesn't work.


No offense intended, I have no clue what is happening other than what i state as what I am seeing.


So what in line one of the install instructions is wrong and what do i need to do?

---------- Post Merged at 22:41 ---------- Previous Post was at 20:37 ----------

oh - just a note that it appears that the biglybt log write thinks the announce is for the spoofed peer-Id,
but by the time it gets sent to the tracker - it seems to quite clearly be unspoofed BBT peer_id

---------- Post Merged on 13.03.20 at 10:10 ---------- Previous Post was on 12.03.20 at 22:41 ----------


No. It works. I'm also behind a VPN.

User-Agent: qBittorrent/4.2.1
Accept-Encoding: gzip
Connection: close

Captured straight from wireshark

Also checked peerlist and I see qBittorrent 4.2.1


Thanks for that.

Then we need to understand what is causing the issue highlighted by HDCD and confirmed by me. Issue may be centered on windows installs, particularly given digitalDJ's comments on no JDK actual install required

I am using win7 64 not Mac - different install processes and OS's


I have seen it send the spoofed ID once through dozens of tests,
I HAVE seen it not send the spoofed ID consistently many times


Its no mistake I've checked it across 2 trackers and with a number of different javas and spoof clients.



I'll also reiterate that my old 5.3 azureus 32 bit install (on win7 64) worked fine (no doubt - I saw the spoofed clients named) sending the spoofed client ID until my first BBT install not long ago. It doesn't anymore on a fresh install, and neither does a fresh install of Azureus 5.7

... although my java install base is almost certainly different from what it was on those tests. :confused:

balalaika
14.03.20, 14:07
Using this thing for a while now and feel generous today, here are my couple cents:smile:
Dockerized version of BiglyBT Extreme Mode:


FROM fullaxx/ubuntu-desktop

ENV DEBIAN_FRONTEND noninteractive
ENV LANG C

# ------------------------------------------------------------------------------
# Install prerequisites and clean up
RUN apt-get update && apt-get upgrade -y && \
apt-get install -y software-properties-common && \
add-apt-repository ppa:openjdk-r/ppa -y && \
apt-get update && \
apt-get install openjdk-13-jre-headless libjna-java -y && \
apt-get install -y --no-install-recommends \
libswt-gtk-3-jni \
libwebkitgtk-3.0-0 \
unzip \
tree && \
sed -e 's/^assistive_technologies/#assistive_technologies/' \
-i /etc/java-13-openjdk/accessibility.properties && \
apt-get clean && \
rm -rf /var/lib/apt/lists/* /var/tmp/* /tmp/*

COPY BiglyBT_*.zip /

# ------------------------------------------------------------------------------
# Install BiglyBT
RUN wget -q https://files.biglybt.com/installer/BiglyBT_Installer.sh -O /app/Big lyBT_Installer.sh && \
chmod +x /app/BiglyBT_Installer.sh && \
USER="root" app_java_home="/usr/lib/jvm/java-13-openjdk-amd64/" /app/BiglyBT _Installer.sh -q && \
rm /app/BiglyBT_Installer.sh && \
unzip -o BiglyBT_*.zip -d "/usr/local/biglybt" && \
rm BiglyBT_*.zip && \
echo "--patch-module=java.base=ghostfucker_utils.jar" >> "${HOME}/.biglybt/j ava.vmoptions" && \
echo "--add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED" >> "${HOME}/ .biglybt/java.vmoptions"

# ------------------------------------------------------------------------------
# Install startup scripts
COPY app/*.sh /app/

# ------------------------------------------------------------------------------
# Identify Volumes
VOLUME /torrent-blackhole
VOLUME /downloads
VOLUME ${HOME}/.biglybt

# ------------------------------------------------------------------------------
# Expose ports
#VNC
EXPOSE 5901
#biglybt WEB UI
EXPOSE 9091

# ------------------------------------------------------------------------------
# Define default command
CMD ["/app/app.sh"]


and docker-compose.yml example NordVPN + radarr + sonarr + jacket + BiglyBT Extreme Mod:


version: "3"
services:
vpn:
image: bubuntux/nordvpn:3.6.1-1
container_name: nordvpn
cap_add:
- net_admin
devices:
- /dev/net/tun
environment:
# check info about hot to configure it here https://github.com/bubuntux/nordvpn#environment-variables
- USER=<put yours>
- PASS=<put yours>
- CONNECT=us -g ptp
- TECHNOLOGY=OpenVPN
- PROTOCOL=UDP
# put sub-network of your router here or a list of them, otherwise you won't be able to access web gui / vnc of any container listed here
- NETWORK=192.168.1.0/24
- TZ=<put yours>
ports:
# biglybt
- 5901:5901
- 9091:9091
# jacket
- 9117:9117
# sonarr
- 8989:8989
# radarr
- 7878:7878
restart: unless-stopped

biglybt:
# put Dockerfile from above to biglybt2 directory
build: ./biglybt2
container_name: biglybt
depends_on:
- vpn
network_mode: "service:vpn"
environment:
- VNCUID=1000
- VNCGID=1000
- VNCUSER=test
- VNCGROUP=tests
- VNCUMASK=0000
- TZ=<put yours>
volumes:
- ./biglybt/config:/home/test/.biglybt
- /your/path/torrent-blackhole:/torrent-blackhole
- /your/path/downloads:/downloads
restart: unless-stopped

jackett:
image: linuxserver/jackett
container_name: jackett
depends_on:
- vpn
- biglybt
network_mode: "service:vpn"
environment:
- PUID=1000
- PGID=1000
- TZ=<put yours>
volumes:
- ./jackett/config:/config
- /your/path/torrent-blackhole:/downloads
restart: unless-stopped

sonarr:
image: linuxserver/sonarr
container_name: sonarr
depends_on:
- vpn
- jackett
network_mode: "service:vpn"
environment:
- PUID=1000
- PGID=1000
- UMASK_SET=0000
- TZ=<put yours>
volumes:
- ./sonarr/config:/config
- /your/path/tv shows:/tv
- /your/path/downloads:/downloads
restart: unless-stopped

radarr:
image: linuxserver/radarr
container_name: radarr
depends_on:
- vpn
- jackett
network_mode: "service:vpn"
environment:
- PUID=1000
- PGID=1000
- UMASK_SET=0000
- TZ=<put yours>
volumes:
- ./radarr/config:/config
- /your/path/movies:/movies
- /your/path/downloads:/downloads
restart: unless-stopped

Sonarr: http://<your_host_IP>:8989/
Radarr: http://<your_host_IP>:7878/
Jacket: http://<your_host_IP>:9117/UI/Dashboard#
BiglyBT Web UI: http://<your_host_IP>:9091/
To connect to BiglyBT GUI use VNC Viewer: <your_host_IP>:5901
This way you have access to BiglyBT GUI and able to configure it at any time in the way you want and web UI as complimentary. Instead of NordVPN you can put your own VPN provider, it's just an example. How to set up Jacket, Radarr, Sonarr and BiglyBt is up to you, check the documentation. You can do it once and forget for a long while.

Terrorizer
16.03.20, 12:04
Hi @all
... any efforts until yet ?
Is there something we could help ???

JP2020
17.03.20, 12:20
I cant do much else without guidance. I'm just running around in circles
It is being looked at by wiser folk than me.

The spoof seems to work apart from client ID as long as you have no java issues
(I have one installed java now used by all - *I think* - not certain as Bigly seems to install some 'stub javas in locallow)


Different java installs can seem to create some issues
GF utils from 1.9 version same result - don't know if thats same content.

Built in azureus spoof client id/version works but can then be compromised by GF spoof in certain ways unless cleared - seemingly even though built in spoof disables the GF spoof

DigitalDJ
17.03.20, 14:16
Are you actually seeing the Client ID reported as BiglyBT on the tracker side? Where are you actually seeing BiglyBT being reported when PerfectSpoof is enabled?

As I said previously, post screenshots of the things I requested previously, if you want any hope of reproducing it.

I still don't know why you are fucking around with Java. All you need to do is extract the ZIP to the jre folder. Nothing else is required.

--->HDBD<---
17.03.20, 15:28
1. BiglyBT 2.3.0.0
2. Java 13.0.2 (64 bit)
3. 20316
4. 20317
5. On these two trackers hdbits.org and bit-hdtv.com I tried and it shows as BiglyBT 2.3.0.0

JP2020
17.03.20, 23:17
Are you actually seeing the Client ID reported as BiglyBT on the tracker side? Where are you actually seeing BiglyBT being reported when PerfectSpoof is enabled?


YES - seemed quite clearly stated by both of us reporting the issue. The trackers know what it is.
If you use the internal BBT version spoof azureus - the tracker report the azureus version
All the bits of ghostfucker spoof seem to work (so java seems to be working) APART from the client ID




[QUOTE=DigitalDJ;356125]As I said previously, post screenshots of the things I requested previously, if you want any hope of reproducing it.


you have been shown screenshots.




I still don't know why you are fucking around with Java. All you need to do is extract the ZIP to the jre folder. Nothing else is required.

i dont know why you keep saying that when
a) already said it don't work
b) doesn't make sense compared to the instructions at the top of every page - but tried it anyway



Already explained the situation with java, repeatedly.
It wont even run with just the linked file 'just extracted' into bbt\jre. It will with the openjdk install extracted. It will with the BBT environment variable set to the installed dir.
BBT itself has a +java install option and installs limited java to the locallow folder in windows and wont start with those deleted.

FFS you can just select show local client and see it say azureus extreme mod or biglybt extreme mod as in the screenprints I sent you and anon. Is it supposed to show that rather than the spoofed ID's/.
- the screenprint showed the spoof peerid with the client id shwoing that the spoof was PARTIALLY working


Think I want to be fucking around with java or anything?

Think I'm wasting this much effort playing some stupid game?




Maybe it is something to do with specific windows installs but in that case:
Why is the peerid being spoofed and the number of peers but NOT the clientId?

I have no idea where I should check for that as I didn't write the code even if i was a java coder.

anon
18.03.20, 04:29
Calm down guys, let's focus on the problem. JP2020, any chances you can capture a BitTorrent peer handshake from the mod using Wireshark? That should clear any doubts as to which identification string (and what else) is sent. You may have to disable protocol encryption.

I haven't had the time to test all of this, but I'll try to do it really soon.

JP2020
19.03.20, 00:24
Can i suggest the first port of call rather than me supplying more proof I'm not bullshitting

# despite the many unanswered issues raised with installation I have read here on various versions - a number of which issues I have now ALSO seen including clicking on the icon to run seeming to result in nothing happening, a java runtime error despite having copied the contents of the apparent specific linked zip file as a jre sub folder replacing the existing jre folder where BBT will have over-written in the previously copied contents of that same specific download zip folder which was copied into a none existent folder that you had to create.




- is sorting out those windows install instructions and confirming that:

a) They make sense and dont expect windows users to understand that 'download and install', doesn't actually mean 'download and install'
let alone something that hasn't got any obvious or even less obvious install, to a directory which may not at that stage exist, or have been deleted as part of troubleshooting 'advice' - or maybe not

b) The process works as literally followed with a 'clean install
(either no prior bigly install or the appdata and program files dirs are deleted as required in the troubleshooting guidance

c) Confirm that the process is not dependent on some prior working installed ... whatever + [optional] let alone fuck that working version up that common sense says shouldn't have been touched by it. (and that before I started cleaning out and deleting old java stuff with the resultant fallout)

d) Perhaps even link to an install that WILL work with the patch available and isn't highly likely to install a version of biglybt that may be later than the patch available.


Because as far as I can see, the existing instructions don't meet any of those basic requirements.
As apparently others than me who have talked here about different java installs have also struggled the same way




Now having delved far more deeply than i would ever have wished, a few notes


The linked java isnt readily installable as it stands, and simply copying doesn't work in at least some circumstances which do seem to be a VERY fresh install, even with older java installs hunted down and deleted breaking other things.


There are three biglybt installs
The stub which chooses itself what to install, and which may end up installing a later incompatible base version
The 64/32 bit specific version installs from github which install a specific version
A version+java ...? (which I think I had to use so long ago despite it being only a relatively few days - just to get the darn thing to run at all)

An obvious question being - does a first install or clean install need a +java install, or does it specifically NOT need that version?






I am currently from an old version that largely worked,
to a version that has its arse hanging out, in a quite obscure way, despite a spoof peerid making it stand out like a baboons arse in mating season, and which has afflicted even new old azureus installs (which previously worked) with that baboons arse affliction,
and my 'fucking about with java' attempting to interpret the install instructions has broken a number of other installs on my system which had been running fine for years.

Its currently uninstalled.



Now some clear, unambiguous install instructions might even result in the issue going away, but at least then we would have a level playing field to work with to see what changes cause the IDENTIFIED issue with the client ID.


I'm done chasing blind

---------- Post Merged at 00:24 ---------- Previous Post was at 00:09 ----------

Perhaps even this from some time ago, which seemingly never got an answer, and that 'outdated is being very 'kind' IMO:



The Windows install instructions seem incredibly outdated.
It should look like this:


Windows

1. Download and install the latest BiglyBT release (https://www.biglybt.com/download/).
2. Download the latest Java JDK GA release Zip file (http://jdk.java.net/13/).
3. BACK UP YOUR TORRENT LIST! IT IS LIKELY YOU WILL LOSE IT!
4. Extract the hack files using 7-Zip (7-Zip Download) or equivalent to %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT) and overwrite ALL files.
5. Delete the "jre" folder in %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT).
6. Open the OpenJDK archive downloaded in step 2 and extract the "jdk-XX" folder to the BiglyBT folder %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT).
7. Rename the extracted "jdk-XX" folder to "jre".
8. Run Notepad as Administrator and open %PROGRAMFILES%\BiglyBT\BiglyBT.exe.vmoptions (C:\Program Files\BiglyBT\BiglyBT.exe.vmoptions), append the following line:
NOTE: If you want to run BiglyBT-console.exe perform step 8 but instead create file "BiglyBT-console.exe.vmoptions"
Code:

--patch-module=java.base=ghostfucker_utils.jar
--add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED

9. Run BiglyBT and Enjoy!



And remove the warning:
"Please note the change of instructions for Java 11. For Java 11 please remove the "--add-exports=java.xml.bind" line from the vmoptions file and use the OpenJDK binaries for Windows and macOS."

from your post as there currently is no
"--add-exports=java.xml.bind" line in your install instruction

Or do you mean the one that says:
"--add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED" ?


Although BBT install failed when I tried it that way with no java installed
So rather than guess/assume further .....

DigitalDJ
19.03.20, 06:22
Perhaps even this from some time ago, which seemingly never got an answer, and that 'outdated is being very 'kind' IMO:

I reviewed this. It was not out of date. A misinterpretation. The additional instructions were for those updating from older versions of BiglyBT using JDK 1.8/1.9.

I will get around to verifying the issue when I have the time.

JP2020
19.03.20, 11:20
No, its not out of date - just wrong right from the first three words.


and bbt still seems to install a (stub/limited?) 1.8 java in \locallow as i've seen in the folder and in the install log.



If you want me to test something reasonable - I will once the install instructions are clarified and work
just not willing to run around in circles anymore with basic questions I and others have asked effectively ignored.


Bigblybt still does a client version check (seen when i was searching the log for 'client')
"VersionCheckClient is using cached version check info. Using 14 reply keys."

Is what I am seeing a cache issue???

WTF is "Delayed task 'Peer Injector (class com.biglybt.util.InitialisationFunctions$2)': queue_time=2369, exec_time=627"

Are the working versions a result of reported failed installs installing something which the finally (mostly) working install relies on?
- i seem to recall getting that impression (perhaps related to biglybt +java version of the biglybt installs)




thoughts:

In client spoofing Set the spoofed clientid to (also?) write to the local client client_id if it doesn't at the moment.
Mine showed either 'BiglyBT extreme mod or azureaus extreme mod if the BBT built in version spoof ids set.
It did/does does not show the spoofed client_id even if built in version spoof is disabled and ghostfuckker spoof set with a client as most will intend to use it.
- you can check this in your install by simply clicking on show local client in peer list

BBT log seems to report its writing the spoofed client_id - although trackers DO know its the original name/version or the version set in the built in version spoof
- as reported by the tracker. Trackers seem to know straight away as demonstrated by the banned client message and the torrent connected peer report in the tracker.
- not sure this is the case in ALL circumstances of a 'borked install. In fact in some problematic installs (as reported here by multiple people) sometimes BBT wont start at all, or options wont come up with a 'you gotta wait till it finishes loading' message
I've seen those to with some of my attempts.



It may be related to some kbxxxx security update NOT installed in some windows as there is a known to me issue with visual c++ runtimes/programs,
the missing MS kbxxx update may not have been installed when win7 users have disabled auto updates - as many have.
- But thats a stretch as SOME of the spoofing works - so NOT fucking with windows security updates based on a vague maybe. To much has been broken already.

DigitalDJ
19.03.20, 15:28
and bbt still seems to install a (stub/limited?) 1.8 java in \locallow as i've seen in the folder and in the install log.


The instructions are correct. The only part that needs clarifying is that installing the JRE means simply to extract the zip to the "jre" folder.

You keep posting so many red herrings. It's difficult to keep up.

There may very well be a problem with PerfectSpoof, and we'll investigate, but it has nothing to do with the install procedure.


Firstly, BiglyBT DOES NOT install Java into AppData\LocalLow. That's a Java install you already have installed on your system. If you have Java 1.8 installed, BiglyBT will use that and not create a "jre" folder in the BiglyBT ProgramFiles folder. However, creating the "jre" folder will always override the JRE that will be used, assuming you start BiglyBT "normally".

The show local client is a BiglyBT 2.3.0.0 feature. I am 99% sure it's purely cosmetic. It has nothing to do with what is sent to the tracker. Yes, it will currently show BiglyBT as the local peer even if PerfectSpoof is on.

If the About window shows Java 13.0.2 and the Extreme Mod settings exist, installation is complete. Full stop. Nothing else. That's it. The end.



It may be related to some kbxxxx security update NOT installed in some windows as there is a known to me issue with visual c++ runtimes/programs,
the missing MS kbxxx update may not have been installed when win7 users have disabled auto updates - as many have.
- But thats a stretch as SOME of the spoofing works - so NOT fucking with windows security updates based on a vague maybe. To much has been broken already.


No. Just no. It almost never is. People who disable auto updates don't know what the fuck they are doing.

If you want to verify what is sent to the tracker, pick a HTTP (not HTTPS) tracker and use Wireshark to determine what gets sent. If that does indeed show the correct information, maybe it is indeed an HTTPS tracker issue, and that's something we'll investigate.

JP2020
19.03.20, 19:16
The show local client is a BiglyBT 2.3.0.0 feature. I am 99% sure it's purely cosmetic. It has nothing to do with what is sent to the tracker. Yes, it will currently show BiglyBT as the local peer even if PerfectSpoof is on.



It also cosmetically shows the spoofed peerid with the selected spoof client prefix, amount done etc etc incredibly accurately for a purely cosmetic line of info as you can see in the screenprint i sent you.

and amazingly, the cosmetic peer_id prefix and key shown changes, undoubtedly purely coincidentally and entirely cosmetically with the spoof selected. Miraculous.


Let alone that as stated, undoubtedly red herringly, that if you set the azureus spoof it says, purely coincidentally azureus extreme mod rather than biglybt extreme mod.


What a set of coincidences.



So your current claim re the unchanged advise to potential users is that it should be

1.
Download the linked jdk GA zip


2.
If you have a biglybt\jre folder - delete the contents and replace with the (version) contents from the download

Else If you have deleted or never installed BBT - Create a program files\biglybt folder and copy the (version) folder extracted into the biglybt folder and rename it jre

3.
Run the bigly install stub. Which will potentially overwrite some of the contents of the jre folder and the install wont then 'fuck around' with temp or locallow folder java extracts that only it seems to know about...

If its successful you should get a 'do you want to start BBT' option (you might not - I didnt on some installs)
Dont select restart - let it end and delete the current jre folder and re- copy/create the jre you had before the install from the download into biglybt\jre



That about right so far?
If so I'll give it a go over the weekend.

anon
20.03.20, 00:44
For the record, here's how I've been running BiglyBT for two years now. This isn't the standard procedure, just my own.

Extract the recommended Java from the first post (OpenJDK 13 in this case) to a custom directory, and append the "bin" subdirectory of it to your %PATH% environment variable. After this, running java -version in any command prompt window should tell you you have Java 13 (as it does for me). There shouldn't be any other runtimes installed anywhere in any shape or form. Try JavaRa and do a manual file and registry search to make sure they're all gone.

Then, install BiglyBT using the official 64-bit installer from their homepage. It will download a Java runtime, but don't worry about that because it won't even be used. Follow the installation procedure normally, then choose not to run the program when finished. Copy the contents of "BiglyBT" under Program Files somewhere else, then immediately uninstall it.

On that copy, delete "jre" and extract the mod's files inside, overwriting everything where applicable. You will not do step 6 of the installation process, instead using the following script to launch the mod (put it in the same place as BiglyBT.jar):


@echo off
rem In case this is called from a terminal window, remember the original working directory
set WD="%CD%"

cd /d "%~dp0"
set VUZEDIR=%CD%
echo Starting BiglyBT...
start "" javaw.exe -Djava.net.preferIPv4Stack=true -classpath "%VUZEDIR%\BiglyBT.jar;%VUZEDIR%\swt.jar" -Djava.library.path="%VUZEDIR%" -Dazureus.portable.enable=true -Dazureus.config.path="%VUZEDIR%" -Duser.dir="%VUZEDIR%" --patch-module=java.base=ghostfucker_utils.jar --add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED com.biglybt.ui.Main
set VUZEDIR=

cd /d %WD%
set WD=


At this point, you can't use BiglyBT.exe to run the mod anymore, because it will complain about not having the "local" JRE it expects. This means file and protocol associations won't work either, but since I don't use those, I didn't consider it a problem. Also, while I did edit the .vmoptions to add those two lines just in case, passing the same parameters via the script should make it unnecessary.

I used this scheme to 1. store all configuration inside the same directory, 2. avoid having multiple Java runtimes installed just for the sake of showing a custom process name and icon in the Task Manager (also did it with jDownloader for the same reasons). The client spoof works fine, "stop torrent when finished" works fine, and I can't reproduce any of the bugs that have been reported for this version.

DigitalDJ
20.03.20, 00:55
It also cosmetically shows the spoofed peerid with the selected spoof client prefix, amount done etc etc incredibly accurately for a purely cosmetic line of info as you can see in the screenprint i sent you.

and amazingly, the cosmetic peer_id prefix and key shown changes, undoubtedly purely coincidentally and entirely cosmetically with the spoof selected. Miraculous.


Let alone that as stated, undoubtedly red herringly, that if you set the azureus spoof it says, purely coincidentally azureus extreme mod rather than biglybt extreme mod.


What a set of coincidences.


God you're insufferable. You talk a lot of shit you know nothing about. If you want to educate yourself and solve the problem, you're more than welcome to decompile and take a look.

All those things, yes, are still generated even though PerfectSpoof is enabled. Last time I checked, local peer is just a dummy entry in the list -- specifically added in 2.3.0.0. I didn't override the interface methods that would implement showing the correct data for that dummy entry. But it'll be revisited when I get the chance.



So your current claim re the unchanged advise to potential users is that it should be


No.

Literally, the instructions are the fucking same, what the fuck. If English isn't your first language, I can understand. However, as I said, the only clarification is step 1:


1. Download the latest OpenJDK Java. It must be Java version 13 or higher. (JDK GA Release (http://jdk.java.net/13/)).
2. Download and install the latest non-beta BiglyBT release (BiglyBT - Download (https://www.biglybt.com/download/)).
3. BACK UP YOUR TORRENT LIST! IT IS LIKELY YOU WILL LOSE IT!
4. Extract the hack files using 7-Zip (7-Zip Download (http://www.7-zip.org/download.html)) or equivalent to %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT) and overwrite ALL files.
5. Delete the "jre" folder in %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT).
6. Open the OpenJDK archive downloaded in step 1 and extract the "jdk-XX" folder to the BiglyBT folder %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT).
7. Rename the extracted "jdk-XX" folder to "jre".
8. Run Notepad as Administrator and open %PROGRAMFILES%\BiglyBT\BiglyBT.exe.vmoptions (C:\Program Files\BiglyBT\BiglyBT.exe.vmoptions), append the following line:
NOTE: If you want to run BiglyBT-console.exe perform step 8 but instead create file "BiglyBT-console.exe.vmoptions"


--patch-module=java.base=ghostfucker_utils.jar
--add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED

9. Run BiglyBT and Enjoy!

If you want to contribute to troubleshooting, as I said previously in my post. Find a HTTP tracker, enable PerfectSpoof, capture the connection with Wireshark.

JP2020
20.03.20, 19:29
Ok
So uninstalled,

Copied the contents of the linked java.zip into biglybt\jre

Ran the bigly stub install (win7 64), and got what i got at the start

Install failed.

https://github.com/BiglySoftware/BiglyBT/issues/157


.. Which says 'install required java to avoid java download issue' - which wunderboy not only says isn't necessary, but shouldn't be done and that my 'fucking with java' was causing the problems






it WILL install with a openjdk java 13.2 jdk properly 'installed' (as i stated)
Possibly/probably would with just a java 13.2 jre 'installed' with the java path variable set (which variables the install searches for per the install log)


... As the instructions have said for years, but just pointed to one that doesn't (obviously at least) install




Just having the linked code copied into the biglybt\jre folder does NOT enable the BBT install to even reall start let alone complete for me. Only having an installed java will.

It will install with the copied code in \jre or the installed openjdk dirs copied in, or with nothing in the biglybt\jre - as long as there is an INSTALLED java

... Which eventually got got me to a running bbt but with the clientid issue which i didn't see until it was raised for the xth time which made me look properly.

---------- Post Merged at 19:29 ---------- Previous Post was at 19:17 ----------


Noch ein mal zu erinnerung Perfect spoof funktioniert nicht auf hdbits und bithdtv wenn jemand ein lösung hat bitte her damit
Installiert ist BiglyBT 2.3.0.0 und Java 13.0.2

One more reminder Perfect spoof does not work on hdbits and bithdtv if someone has a solution please bring it here
Installed is BiglyBT 2.3.0.0 and Java 13.0.2
20310

Thanks again for highlighting this despite the grief i'm getting
Does any of teh install issues i detail look familiar? Your experiences might help identifying

As a side note, I'm sure the issue isn't related to specific trackers OR that everyone will be experiencing this - I saw one of my install versions report the spoofed client id correctly but didn't document the tests properly - but will try and remember - re-do


I believe its just some trackers would flag/reject it as an undesirable client and some wont.
the ones i tried don't ban BBT i just looked in the peerlist/connected peers info (in the trackers).

DigitalDJ
21.03.20, 06:57
The instructions very clearly say to place the extracted zip into the JRE folder AFTER you install BiglyBT. In this case, it should also always be the full installer, not the stub installer.

JP2020
21.03.20, 10:01
The 'stub' installer is what the instructions link, and does an online install rather than a full 'offline' installer which would have everything built in.

As already stated, i tried it both ways and many more, although you clearly ignore that like you have all the other times we see people have raised these sort of issues.

I do understand if you are clueless - I'm the same,
but in that case stop pretending you aren't and just shut the fuck up while we try and sort out what the problems are ... if anyone else will help given the shit you dish out.
... Especially as you almost certainly dont even use anything like a 'normal' as described (LOL) way to fire up BBT


You are effectively saying:
You aren't following the actually still wrong instructions where the install and/or following start of BBT fail - and where people trying to use it are immediately thrown off at a tangent,
.. and 'My completely different way of installing/running works fine ... so you (us) are doing it wrong.



Only the biglybt+java install seems to 'work' without an installed java for me. I don't know why. My java skills are negligible as stated.
https://github.com/BiglySoftware/BiglyBT/releases

That installs JAVA_VERSION="1.8.0_202" in biglybt\jre
after which whatever you stick in biglybt\jre generates errors and it only runs using an installed java (openjdk 13.2 as stated)
When you eventually get a working bbt after 'fucking around with java' the spoof features largely work apart from client_id
- and trackers know what bbt client you are running both in the tracker connections client rejection script and in the connected client shown in multiple trackers including old http trackers AS STATED.



I dont know why the earlier installs (still incorrectly re install/copy at least) refer to jre rather than more recent ones stating jdk



After retrying according to your half baked comments, i currently dont have any form of working bbt or azureus.

DigitalDJ
21.03.20, 17:12
The 'stub' installer is what the instructions link, and does an online install rather than a full 'offline' installer which would have everything built in.

Frankly, it shouldn't matter. The stub or full installer will work. The instructions link the BiglyBT download page. The BiglyBT download page will pick the appropriate installer for your system. On Firefox, Windows 10 64-bit, it will automatically download the full 64-bit Windows installer, not the stub. You do not need Java installed to install BiglyBT.

On a machine with no Java install and no BiglyBT, both installers work. Stub and full. After installing the stub, you end up with a BiglyBT folder in Program Files that contains a jre folder. The included JRE version is 1.8.0_202. That JRE version is required for vanilla BiglyBT, but the mod requires 13+.

If either the BiglyBT installer does not run, or after clean installing BiglyBT, BiglyBT does not run, then this isn't a problem with the mod. You need to take your problem to the BiglyBT developers.

Chances are with all your fucking around with Java, you have pointer somewhere to an inappropriate Java install. Could be environment variables (i.e. PATH / JAVA_HOME), could be a number of things. Plenty of resources over at Google to help you figure that out.

Regardless, once you follow the instructions to install the mod...even if you DO have a broken Java install, correctly placing the contents of the JDK 13 into the BiglyBT\jre folder will override any broken Java install.

You can continue to autistically go over the install instructions repeatedly, and scream bloody murder that it said "download and install" instead of just "download" the JDK, but quite frankly I give zero fucks. This isn't for people who can't operate a computer system. There's not enough seconds in this world for me to give a fuck and take abuse from someone that can't string together a couple of coherent sentences. There's been plenty of clarification on how to get it installed correctly. Apart from the minor correction in step one, all installation instructions are still accurate and have been re-tested.

If you want to actually contribute to solving the PerfectSpoof problem, as I've said several times now, packet capture a non-SSL tracker update with Wireshark and provide the data. Until then, adios.

--->HDBD<---
21.03.20, 18:28
So @DigitalDJ I've tried every troubleshooting measure you've proposed. Currently my main concern is if you are actually listening to any kind of negative feedback, or if you just don't understand the problems highlighted by JP2020.
After trying various solutions you've recommended to solve Perfect Spoof not working on HDBits and and BitHDTV is still showing me as a leecher with my BT client being BiglyBT 2.3.0.0 instead of qBitTorrent 4.2.1
Thank you very much for your efforts to solve this problem but you don't seem to understand that we are trying to report whats not working to actually move ahead in this discussion.

As for any installation issues: I haven't had any JP2020, despite reinstalling it numerous times

JP2020
21.03.20, 20:40
As for any installation issues: I haven't had any JP2020, despite reinstalling it numerous times

Thanks for that. So my installation issues would seem likely to be unrelated to the client_id problem

What you might try is changing the version spoof using the contents of BiglyBTSpoof.properties if Azureus isn't banned - it should disable the GF spoofs anyway - but check that no spoofed fields 'hangover'


#BiglyBT / Vuze / Azureus Perfect Spoof ;)
#By Shu
#No check are being done on what's entered !
#Enter valid version numbers otherwise you'll be detected as Unknown/Fake client
#Example :
#2.5.0.4
#3.0.2.2
#3.0.2.3_B11
#To activate it write azureus.spoof.boolean=True
#To deactivate it write azureus.spoof.boolean=False
#Spoof BiglyBT azureus.spoof.spoofbiglybt=True
#Spoof Azureus / Vuze azureus.spoof.spoofbiglybt=False
azureus.spoof.boolean=True
azureus.spoof.spoofbiglybt=False
azureus.spoof.value=5.7.5.0


When i tried it showed in the tracker as Azureus (version)





Could i ask you to clarify what you actually did being as the first 'install java' instruction is under such confusion, and if you did anything other than simply run the BBT installer linked as step to? and if you had/have a java installed?
Might help me see whats going wrong.







Regarding my issues, and for info
https://github.com/BiglySoftware/BiglyBT/issues/583

maybe Need to try the version there but need to look up what the 1.8 vs 13.2 etc version numbers mean.


Does seem like installing jre rather than jdk makes little if any actual difference.


Seems to be less glitches like magnets giving a similar java library error (but working OK as copy link into open works fine) if java installed before BBT install rather than after for me with openjdk. No idea why, and not ceratin install sequence is the cause/fix.


'the procedure entry point ucrtbase.terminate could not be located in the dynamic link library
api-ms-win-crt-runtime-i1-1-0.dll'


Thought i had remembered what I did the one time the client_id worked ok, but perhaps not. Its still showing biglybt (version)
- maybe it was just a fluke or wishful thinking.

DigitalDJ
22.03.20, 06:36
So @DigitalDJ I've tried every troubleshooting measure you've proposed. Currently my main concern is if you are actually listening to any kind of negative feedback, or if you just don't understand the problems highlighted by JP2020.
After trying various solutions you've recommended to solve Perfect Spoof not working on HDBits and and BitHDTV is still showing me as a leecher with my BT client being BiglyBT 2.3.0.0 instead of qBitTorrent 4.2.1
Thank you very much for your efforts to solve this problem but you don't seem to understand that we are trying to report whats not working to actually move ahead in this discussion.

As for any installation issues: I haven't had any JP2020, despite reinstalling it numerous times

As I've said multiple times. There may very well be a problem with PerfectSpoof. I haven't had time to really had a deep look into it.

The installation issue that JP2020 has absolutely nothing to do with the potential issue.

To help track down the issue, as I've recommended previously: Install Wireshark, packet capture a HTTP tracker update with PerfectSpoof enable, and share the results. Happy for you to censor any private information -- torrent hashes, pass hashes etc.

--->HDBD<---
22.03.20, 12:26
Here a capture
20323

DigitalDJ
22.03.20, 14:17
Thank you, this is actually extremely useful. I'll look into it as soon as I can.

anon
23.03.20, 04:35
Alright, today I took the time to do a completely clean install, following the procedure in the first post, just as if I'd never used the mod before. It worked. There are no error messages, it runs, the spoof works, "stop torrent when completed" works, everything is fine. So JP2020, I honestly have no idea what's causing you so much trouble here. But you're welcome to try running the mod using the script I posted before; actually, please use this slightly modified one instead.


@echo off
rem In case this is called from a terminal window, remember the original working directory
set WD="%CD%"

cd /d "%~dp0"
rem Directly use the Java you set up in steps 5, 6 and 7 of the Extreme Mod install procedure
set JAVA_HOME=%CD%\jre
set BBTEMDIR=%CD%
echo Starting BiglyBT Extreme Mod...
rem I removed the parameters that make it portable
start "" "%JAVA_HOME%\bin\javaw.exe" -classpath "%BBTEMDIR%\BiglyBT.jar;%BBTEMDIR%\swt.jar" -Djava.library.path="%BBTEMDIR%" --patch-module=java.base=ghostfucker_utils.jar --add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED com.biglybt.ui.Main
set JAVA_HOME=
set BBTEMDIR=

cd /d %WD%
set WD=


Then open the mod using that as a replacement for BiglyBT.exe. This has to work regardless of whether you have zero, one or more runtimes of any version already installed anywhere or whether they are operational or not... but well, the same should be true of the executable (and it was during my tests).

anon
23.03.20, 04:35
HDBD, that screenshot is pretty interesting, because everything other than the User-Agent is as it should be for qBittorrent 4.2.1. So the spoof isn't completely broken (which makes this even more puzzling).

First of all, it should be noted that as of this writing, there are three spoofing features in this mod.

Perfect Spoof 2 by ghostfucker, which is the flagship one
Shu's Perfect Spoof, controllable via a .properties file. Backported from the Legitbly mod but not really relevant here
The Client Identification plugin included in the official BiglyBT

No. 2 is not a problem as long as left disabled. My guess is that the third one is interferring with the first under certain configurations or conditions, but once again, I have been completely unable to reproduce that during testing. Please try the following.

Stop all torrents, disable ghostfucker's Perfect Spoof and close the mod.
If by any chance you edited BiglyBTSpoof.properties, replace it with an unmodified copy.
Open the mod. Don't start any torrents, but open the Options panel and make sure that...

Tracker -> Client: "Send Java version and OS name" is enabled (the default).
Plugins -> Client Identification: Client is set to "BiglyBT 2.3.0.0" (the default).
Plugins: "bgclientid" is unticked.
Restart the mod. Enable ghostfucker's Perfect Spoof and pick the client you want. Restart again.

With those settings, it works fine for me. Verified with Wireshark on Pornolab (HTTP tracker) and IPTorrents (HTTPS, but shows your User-Agent on the torrent list), tested spoofing both uTorrent and qBittorrent.

DigitalDJ
23.03.20, 05:47
HDBD, that screenshot is pretty interesting, because everything other than the User-Agent is as it should be for qBittorrent 4.2.1. So the spoof isn't completely broken (which makes this even more puzzling).

First of all, it should be noted that as of this writing, there are three spoofing features in this mod.

Perfect Spoof 2 by ghostfucker, which is the flagship one
Shu's Perfect Spoof, controllable via a .properties file. Backported from the Legitbly mod but not really relevant here
The Client Identification plugin included in the official BiglyBT

No. 2 is not a problem as long as left disabled. My guess is that the third one is interferring with the first under certain configurations or conditions, but once again, I have been completely unable to reproduce that during testing. Please try the following.

Stop all torrents, disable ghostfucker's Perfect Spoof and close the mod.
If by any chance you edited BiglyBTSpoof.properties, replace it with an unmodified copy.
Open the mod. Don't start any torrents, but open the Options panel and make sure that...

Tracker -> Client: "Send Java version and OS name" is enabled (the default).
Plugins -> Client Identification: Client is set to "BiglyBT 2.3.0.0" (the default).
Plugins: "bgclientid" is unticked.
Restart the mod. Enable ghostfucker's Perfect Spoof and pick the client you want. Restart again.

With those settings, it works fine for me. Verified with Wireshark on Pornolab (HTTP tracker) and IPTorrents (HTTPS, but shows your User-Agent on the torrent list), tested spoofing both uTorrent and qBittorrent.

I suspect it is indeed the Client Identification plugin. It does indeed include code to add a User-Agent to tracker requests. Although, I'm still going to work through all the patches we apply and ensure they're been applied in the correct locations.

anon
23.03.20, 07:14
Honestly, they should get rid of that already. It's no longer necessary - the transition stage is over, BiglyBT is the new Vuze - and trackers are always going to frown upon a client that has ID spoofing features out of the box. Even if the intentions behind it are good and it only allows a very limited set of choices.

DigitalDJ
23.03.20, 12:52
Honestly, they should get rid of that already. It's no longer necessary - the transition stage is over, BiglyBT is the new Vuze - and trackers are always going to frown upon a client that has ID spoofing features out of the box. Even if the intentions behind it are good and it only allows a very limited set of choices.

AFAIK, they did remove it in 2.3.0.0, but I specifically reverted that commit to keep the plugin. I'm interested as to why it's now causing problems...or maybe it was always a thing. I still need to confirm whether that is actually the issue.

---------- Post Merged at 20:52 ---------- Previous Post was at 16:00 ----------

HDBD, can you please elaborate more on your setup. I just reviewed the code and things look OK. I personally tried a HTTP tracker and confirmed the qBT 4.2.1 spoof works.

I'm curious as to why in your About Window it says "N/A" under Java 13.0.2. It should be "Oracle Corporation". This is probably a red herring.

Can you:

- screenshot your full Extreme Mod settings
- open a command prompt and post the output of the following:
cd "C:\Program Files\BiglyBT\jre\bin"
java -XshowSettings:properties -version
- Mention if any trackers for which you find PerfectSpoof works?
- share the sources tab for a torrent (censor hostnames, and any other sensitive info)?
- list the contents of:
%APPDATA%\BiglyBT\plugins
%PROGRAMFILES%\BiglyBT\plugins
- share the "Connections" tab in BiglyBT settings
- the contents of %PROGRAMFILES%\BiglyBT\BiglyBTSpoof.properties

usernom
23.03.20, 17:54
@DigitalDJ

Could you please provide the attachment to those of us who do not care about spoofing at all?
All I need is "no upload" and automatic removal after finish. I couldn't care less about spoofing.

2.2.0.2 Beta is a mess for me. Automatic removal is completely broken and it has just crashed and corrupted its settings for the second time in 24h. I'd like to at least try and see if 2.3.0.0 works better.

Thank you very much for your hard work.

--->HDBD<---
24.03.20, 09:37
@DigitalDJ

I don't have too much time right now.
about weekends i will inform more

anon
25.03.20, 02:36
I just cleaned up the thread of "where's the download link" posts, and rolled the sticky and announcement lists back to 2.2.0.2 until we can reupload this version.

--->HDBD<---
26.03.20, 00:31
1. I don't know why it was shown as N/A but now it looks like
20329

2. Here are the Extreme Mod settings
20330
20331

3. java -XshowSettings:properties -version

Microsoft Windows [Version 10.0.18363.720]
(c) 2019 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\xxxxxxx>cd "C:\Program Files\BiglyBT\jre\bin"

C:\Program Files\BiglyBT\jre\bin>java -XshowSettings:properties -version
Property settings:
file.encoding = Cp1252
file.separator = \
java.class.path =
java.class.version = 57.0
java.home = C:\Program Files\BiglyBT\jre
java.io.tmpdir = C:\Users\xxxxxxx\AppData\Local\Temp\
java.library.path = C:\Program Files\BiglyBT\jre\bin
C:\WINDOWS\Sun\Java\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler
C:\Program Files (x86)\Intel\iCLS Client\
C:\Program Files\Intel\iCLS Client\
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\WINDOWS\System32\OpenSSH\
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL
C:\Program Files\Intel\Intel(R) Management Engine Components\DAL
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT
C:\Program Files\Intel\Intel(R) Management Engine Components\IPT
C:\Program Files\IDM Computer Solutions\UltraEdit
C:\Program Files\IDM Computer Solutions\UltraCompare
C:\Program Files\PuTTY\
C:\Program Files\ojdkbuild\java-13-openjdk-13.0.1-2\missioncontrol\
C:\Program Files\ojdkbuild\java-13-openjdk-13.0.1-2\bin
C:\Users\xxxxxxx\AppData\Local\Microsoft\WindowsAp ps

.
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 13.0.2+8
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 13
java.vendor = Oracle Corporation
java.vendor.url = https://java.oracle.com/
java.vendor.url.bug = https://bugreport.java.com/bugreport/
java.version = 13.0.2
java.version.date = 2020-01-14
java.vm.compressedOopsMode = Zero based
java.vm.info = mixed mode, sharing
java.vm.name = Java HotSpot(TM) 64-Bit Server VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Oracle Corporation
java.vm.specification.version = 13
java.vm.vendor = Oracle Corporation
java.vm.version = 13.0.2+8
jdk.debug = release
line.separator = \r \n
os.arch = amd64
os.name = Windows 10
os.version = 10.0
path.separator = ;
sun.arch.data.model = 64
sun.boot.library.path = C:\Program Files\BiglyBT\jre\bin
sun.cpu.endian = little
sun.cpu.isalist = amd64
sun.io.unicode.encoding = UnicodeLittle
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = Cp1252
sun.management.compiler = HotSpot 64-Bit Tiered Compilers
sun.os.patch.level =
sun.stderr.encoding = cp850
sun.stdout.encoding = cp850
user.country = LI
user.dir = C:\Program Files\BiglyBT\jre\bin
user.home = C:\Users\xxxxxxx
user.language = de
user.name = xxxxxxx
user.script =
user.variant =

java version "13.0.2" 2020-01-14
Java(TM) SE Runtime Environment (build 13.0.2+8)
Java HotSpot(TM) 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing)

C:\Program Files\BiglyBT\jre\bin>

4. On This Tracker PerfectSpoof works
20332

5. %APPDATA%\BiglyBT\plugins
20333

6. %PROGRAMFILES%\BiglyBT\plugins
20334

7. %PROGRAMFILES%\BiglyBT\BiglyBTSpoof.properties

#BiglyBT / Vuze / Azureus Perfect Spoof ;)
#By Shu
#No check are being done on what's entered !
#Enter valid version numbers otherwise you'll be detected as Unknown/Fake client
#Example :
#2.5.0.4
#3.0.2.2
#3.0.2.3_B11
#To activate it write azureus.spoof.boolean=True
#To deactivate it write azureus.spoof.boolean=False
#Spoof BiglyBT azureus.spoof.spoofbiglybt=True
#Spoof Azureus / Vuze azureus.spoof.spoofbiglybt=False
azureus.spoof.boolean=False
azureus.spoof.spoofbiglybt=True
azureus.spoof.value=2.3.0.0

DigitalDJ
26.03.20, 01:11
Thanks, can you also share the Sources tab for a tracker that you think PerfectSpoof does not work for?

This is puzzling. Cheers

--->HDBD<---
26.03.20, 09:04
PerfectSpoof does not work for bit-hdtv.com

20340
20341

the same on hdbits.org

DigitalDJ
26.03.20, 11:36
Hmm HTTP vs HTTPS. Gives me some idea where to look. Thanks.

You don't happen to be using a proxy?

--->HDBD<---
26.03.20, 12:06
No, I do not use proxy.

JP2020
28.03.20, 12:00
I'll not go into too much detail as what I have seen in install tracking and tests directly contradicts digitaldjs statements.
I dont doubt that what he says has and does happen for him, its just that the assumptions he seems to have made from that are simply wrong.
He'll need to accept that before he'll find the issue.


I don't think there is anything wrong with the spoof code.

* Digitaldj and anon and a mac user who has checked (thank you) and others are not seeing this issue
- and I simply don't accept that all those others are all just missing it, or been banned and said nowt.
for them its working and its the SAME CODE



So whats causing it?

Despite what digitaldj believes is the case, I have tracked the biblyby i4jwhatever install doing all sorts of weird shit with java during its install with temp, localalow and roaming dirs, and it logged searching all over for java installs.


Fore SOME people the java BBT install fails - as it has in certain largely unresolved cases for years in not just BBT but also in minecraft installs.
The response on the BBT foruma and the minecraft forums could have been written by digitaldj (on a good day)


To confirm what I was seeing, I Stripped all java out of my system and just installed open jdk, and copied the installed dir into the \biglybt\jre folder with BBT etc all uninstalled and deep stripped using commodo.


Heres the result straight from the install log

[0:148] No JRE included
[0:148] LoadDLL (0, (null), 0)
[0:148] Searching for a JVM
[0:149] MinVersion: 1.8.0_172, MaxVersion: 1.11
[0:149] Testing location (type Y)
[0:150] Testing location JAVA_HOME (type E)
[0:150] checkJavaExe (C:\Program Files\AdoptOpenJDK\jre-13.0.2.8-hotspot\\bin\java.exe, [out], 4, 2, 0)
[0:150] file exists
[0:150] got version from registry 13.0.2" 2020-01-1
[0:151] checkJavaExe returning 0
[0:151] Testing location JDK_HOME (type E)
[0:151] checking app id allinstdirs0112-2557-8304-7048 (0, FFFFFFFF80000001)
[0:151] could not query value node 0
[0:151] checking app id allinstdirs0112-2557-8304-7048 (256, FFFFFFFF80000001)
[0:152] could not query value node 0
[0:152] checking app id allinstdirs0112-2557-8304-7048 (0, FFFFFFFF80000002)
[0:152] could not query value node 0
[0:152] checking app id allinstdirs0112-2557-8304-7048 (256, FFFFFFFF80000002)
[0:152] could not query value node 0
[0:153] Search sequence finished
[0:153] ERROR: No JVM found
[0:153] Download location: https://www.biglybt.com/jre/win64
[0:153] Downloading JRE
[3:813] ERROR: InternetOpenUrl failed with error code 12157
[4:814] ERROR: Retry JRE download
[6:649] ERROR: InternetOpenUrl failed with error code 12157
[7:649] ERROR: Retry JRE download
[9:398] ERROR: InternetOpenUrl failed with error code 12157
[10:398] ERROR: Retry JRE download



this is an issue reported in the Bigly and minecraft and other forums.


so despite java being installed, the right version, and it finding it after checking its own temp files and failing to find one, it says /not found and tries and fails to download a java.


Biglybt with java install is teh only insstall that works for me, and others will *seem* to work once that has set up the versions in locallow




I'm quite sure that its something to do with the i4j install of biglybt itself and MAYBE what it creates as part of the install (before we copy the patch across) with the JVM/runtime that causing the issue.


Do remember i know fuck all about java. i have explained as best I can.
That java download issue is nothing to do with my connection.



Posts here show this issue affecting some users at least as far back as 1.9, and the 'java' install issue issue has affected a number of java progs for a number of years.

DigitalDJ
29.03.20, 05:54
I'll not go into too much detail as what I have seen in install tracking and tests directly contradicts digitaldjs statements.
I dont doubt that what he says has and does happen for him, its just that the assumptions he seems to have made from that are simply wrong.
He'll need to accept that before he'll find the issue.


I don't think there is anything wrong with the spoof code.

* Digitaldj and anon and a mac user who has checked (thank you) and others are not seeing this issue
- and I simply don't accept that all those others are all just missing it, or been banned and said nowt.
for them its working and its the SAME CODE



So whats causing it?

Despite what digitaldj believes is the case, I have tracked the biblyby i4jwhatever install doing all sorts of weird shit with java during its install with temp, localalow and roaming dirs, and it logged searching all over for java installs.


Fore SOME people the java BBT install fails - as it has in certain largely unresolved cases for years in not just BBT but also in minecraft installs.
The response on the BBT foruma and the minecraft forums could have been written by digitaldj (on a good day)


To confirm what I was seeing, I Stripped all java out of my system and just installed open jdk, and copied the installed dir into the \biglybt\jre folder with BBT etc all uninstalled and deep stripped using commodo.


Heres the result straight from the install log

[0:148] No JRE included
[0:148] LoadDLL (0, (null), 0)
[0:148] Searching for a JVM
[0:149] MinVersion: 1.8.0_172, MaxVersion: 1.11
[0:149] Testing location (type Y)
[0:150] Testing location JAVA_HOME (type E)
[0:150] checkJavaExe (C:\Program Files\AdoptOpenJDK\jre-13.0.2.8-hotspot\\bin\java.exe, [out], 4, 2, 0)
[0:150] file exists
[0:150] got version from registry 13.0.2" 2020-01-1
[0:151] checkJavaExe returning 0
[0:151] Testing location JDK_HOME (type E)
[0:151] checking app id allinstdirs0112-2557-8304-7048 (0, FFFFFFFF80000001)
[0:151] could not query value node 0
[0:151] checking app id allinstdirs0112-2557-8304-7048 (256, FFFFFFFF80000001)
[0:152] could not query value node 0
[0:152] checking app id allinstdirs0112-2557-8304-7048 (0, FFFFFFFF80000002)
[0:152] could not query value node 0
[0:152] checking app id allinstdirs0112-2557-8304-7048 (256, FFFFFFFF80000002)
[0:152] could not query value node 0
[0:153] Search sequence finished
[0:153] ERROR: No JVM found
[0:153] Download location: https://www.biglybt.com/jre/win64
[0:153] Downloading JRE
[3:813] ERROR: InternetOpenUrl failed with error code 12157
[4:814] ERROR: Retry JRE download
[6:649] ERROR: InternetOpenUrl failed with error code 12157
[7:649] ERROR: Retry JRE download
[9:398] ERROR: InternetOpenUrl failed with error code 12157
[10:398] ERROR: Retry JRE download

this is an issue reported in the Bigly and minecraft and other forums.


so despite java being installed, the right version, and it finding it after checking its own temp files and failing to find one, it says /not found and tries and fails to download a java.


Biglybt with java install is teh only insstall that works for me, and others will *seem* to work once that has set up the versions in locallow




I'm quite sure that its something to do with the i4j install of biglybt itself and MAYBE what it creates as part of the install (before we copy the patch across) with the JVM/runtime that causing the issue.


Do remember i know fuck all about java. i have explained as best I can.
That java download issue is nothing to do with my connection.



Posts here show this issue affecting some users at least as far back as 1.9, and the 'java' install issue issue has affected a number of java progs for a number of years.

Fuck me dead, why are you still sytem-installing an unsupported JRE install? Adopt's OpenJDK is /not/ supported. It's absolutely not the same as the OpenJDK zip that is linked in the original post. Not to mention, I have said repeatedly, that "installing" simply means extracting the ZIP file to the BiglyBT\jre folder. This is AFTER you successfully install BiglyBT.

HBDB posted a Wireshark output showing the User-Agent being sent over the wire. If you read the posts, we've already identified there might actually be something wrong with the "spoof code".




so despite java being installed, the right version, and it finding it after checking its own temp files and failing to find one, it says /not found and tries and fails to download a java.


WTF? Can you read the logs?

[0:149] MinVersion: 1.8.0_172, MaxVersion: 1.11

I said before, stock BiglyBT DOES NOT support JRE 13. The log line above clearly states, Java 1.8 through Java 1.11. That is why the installer is trying to download the JRE.

As for the download of the JRE. Have you actually tried accessing https://www.biglybt.com/jre/win64 in Internet Explorer?

Whatever you've done to your Windows install, that link is inaccessible to the install4j BiglyBT installer. Wouldn't be surprised if it's some crap-ware "anti-virus" that is SSL inspecting and causing problems validating certificates.

JP2020
29.03.20, 11:14
You need to make you mind up rather than spouting self contradictory bollocks every farts end

"Download and install the latest OpenJDK Java. It must be Java version 13 or higher."


Which I have done, and copied the contents to the biglybt\jre folder


All else is done by the biglybt install NOT ME



and these issues go back as far as I've looked through the thread right back to 1.8 so far - all fucking ignored.



I may know fuck all about java, but I have years of experience as a coder. system tester and analyst
You seem to be nothing more than a one trick Digital Dick Jerker who i wouldn't employ and who clearly just seemed to have dropped lucky bodging a better mans code else and who would otherwise have ever been a nobody you undoubtedly actually are.


Sort out why when we are all supposedly running the same better mans patched code, different results come out.
Its pretty basic stuff for a real coder.

DigitalDJ
29.03.20, 13:35
You need to make you mind up rather than spouting self contradictory bollocks every farts end

"Download and install the latest OpenJDK Java. It must be Java version 13 or higher."


Which I have done, and copied the contents to the biglybt\jre folder


All else is done by the biglybt install NOT ME


The log you provided shows that the BiglyBT installer is still detecting your Adopt OpenJDK install.

As I said in my previous post, open up that link from the logs in Internet Explorer and see if it downloads. Again, this has nothing to do with the mod. It's either your internet connectivity, or something you have installed/set that is blocking that link. This is obviously why the BiglyBT installer which includes the JRE works --- because the download doesn't fail....the JRE is included.



I may know fuck all about java, but I have years of experience as a coder. system tester and analyst
You seem to be nothing more than a one trick Digital Dick Jerker who i wouldn't employ and who clearly just seemed to have dropped lucky bodging a better mans code else and who would otherwise have ever been a nobody you undoubtedly actually are.


I guess you got what you paid for?

Years of experience as a coder, can't follow numbered instructions. Something doesn't add up.

These are the instructions I specifically provided to you in a previous post:

1. Download the latest OpenJDK Java. It must be Java version 13 or higher. (JDK GA Release (http://jdk.java.net/13/)).
2. Download and install the latest non-beta BiglyBT release (BiglyBT - Download (https://www.biglybt.com/download/)).
3. BACK UP YOUR TORRENT LIST! IT IS LIKELY YOU WILL LOSE IT!
4. Extract the hack files using 7-Zip (7-Zip Download (http://www.7-zip.org/download.html)) or equivalent to %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT) and overwrite ALL files.
5. Delete the "jre" folder in %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT).
6. Open the OpenJDK archive downloaded in step 1 and extract the "jdk-XX" folder to the BiglyBT folder %PROGRAMFILES%\BiglyBT (C:\Program Files\BiglyBT).
7. Rename the extracted "jdk-XX" folder to "jre".
8. Run Notepad as Administrator and open %PROGRAMFILES%\BiglyBT\BiglyBT.exe.vmoptions (C:\Program Files\BiglyBT\BiglyBT.exe.vmoptions), append the following line:
NOTE: If you want to run BiglyBT-console.exe perform step 8 but instead create file "BiglyBT-console.exe.vmoptions"


--patch-module=java.base=ghostfucker_utils.jar
--add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED

9. Run BiglyBT and Enjoy!

If you read and execute them in the correct order. You'll end up with a working install, provided you don't have a bum-fucked Windows install. Feel free to fire up a fresh Virtual Machine and give it a shot.

As you can clearly see. It says to download the JDK in step 1, it does not say to extract until step 6.

I asked you multiple times to provide more information to help debug the issue, including Wireshark captures, and you did not provide it. Instead you insisted the problem be with a bunch of red-herrings, which I have since confirmed are not the issue. HBDB has provided packet captures that has helped debug the issue, and that's what we're going with to identify the issue.......when I have free time.

Until then, fuck off.

JP2020
29.03.20, 22:47
ah back to not install now is it

download and install
Dont install just copy
Just copy in a later step
version 13
Not version 13 needs to be version x-xx


Already explained the steps and it failing as have others all the way back, All you have done is ignored and shown your ignorance
Stange how your story changes when evidence is dumped in yoru lap - but still wrong.



I stripped all the bigly shit out of reg and temp and locallow and roaming that you say it doesn't install and the old azureus 32 bit went straight in with an old 32 bit java no probs. All working.


I've already asked anon to delete this account - you aint worth my effort to help resolve YOUR shit

Pull your head out of your ass - maybe it might start to sound a little less like you are just talking shit to protect your ego rather than working with to resolve issues.

Sazzy
29.03.20, 23:34
Now now, boys. Can we please just all get along? No need to get so pissed off at each other. Let's all play nice, shall we?
This thread is getting a bit too bitter and we all appreciate the work DDJ is putting in. Keep in mind we're all volunteers here.

DigitalDJ
30.03.20, 05:13
ah back to not install now is it

download and install
Dont install just copy
Just copy in a later step
version 13
Not version 13 needs to be version x-xx


Already explained the steps and it failing as have others all the way back, All you have done is ignored and shown your ignorance
Stange how your story changes when evidence is dumped in yoru lap - but still wrong..

Happy to admit that "Download and Install" is misleading for step 1, but that doesn't mean go and install a JDK/JRE that hasn't been linked in the post.

I have consistently clarified to you that the JDK/JRE does not need installing. Simply extract to the BiglyBT\jre folder after successfully installing BiglyBT. Except for that clarification in step 1, the instructions are identical to the original post. It has always been the case that you extract after successful installation of BiglyBT (i.e. step 6).

And yes, messaging related to Java versioning is correct:

- BiglyBT, with the mod, requires JDK/JRE 13 (same as 1.13).
- BiglyBT, without the mod, requires Java 8 (1.8).

In both cases, you do not have to system-wide install ANY Java. By default, the BiglyBT installer will go off and download Java 8 and put it in the BiglyBT\jre folder. This is why after installing the mod, you replace the BiglyBT\jre folder with Java 13, since that is what is required to run the mod.

In your case, the installer is trying to download the JRE but it fails. Unfortunately, this has nothing to do with mod. If you wish, you can use the offline BiglyBT installer which includes the JRE, but you still need to replace the JRE as per step 6 to get the mod to run.

If you're unable to interpret the English in this post, this really isn't for you.

JP2020
01.04.20, 12:41
and as I've told you - doesn't work for me without an INSTALLED java 13

Bigly install fails fetching the java once all the other javas installed on the system are deleted - to try and resolve the issue with biglybt not downloading the one it wants in the install and understand the cause.

Biglybt+java from github installs and works without your mod applied



Once your stuff is copied over and the 13 java extract is copied - it dont work without an installed java and path set (even if local bbt variable is set)


Once java is installed and path set (minimum) - EM bigly will run and about will say its using the bigly\jre and the mods will show
- but removal the path pointer or the actual java install leaving just the copied extract in the biglybt\jre and it wont run


Whether this is the cause of the user agent/client id issue I'm unsure, but I have little doubt its related even though hdbd had no install issue (possibly because he had a usable java already somewhere - possibly the install issue is separate).
I had even removed the jvm.dll's from windows\system to set the flat playing field.


Similar issues have been reported here (in less detail and ignored) since 2017 at least, which is as far back as I have looked.
The issue isn't unique to biglybt, and is reported on games and professional tool forums. Nor have i found a consistent cause or answer




Most people have some java installed somewhere - and the BBT install searches for them and seems happy to use ones it likes.

I cleared all java out to set a level playing field. I doubt many others have.


You saying 'I see no issues' doesn't change any of this.


... and you still haven't even sorted even that first line of the instructions issue despite it having been raised again and again here long before I did.


IF java creates dlls or whatever as part of the install as some interpreted languages I have worked with in the past do, then I would initially guess your code is missing accessing one created in certain circumstances of the core bigly install
other than that I would expect everyone to get the same issue.
Unless everyone who ended up with the issue I describe (whether they know it or not) ends up using something OUTSIDE the expected java for some reason - although as the installed version is still 13.2 - seems unlikely.

I install Biglybt using the java it needs (+java is the same version java it tries to download)

Post that, I tried copying the linked extract, a different zip extract or 4 from openjdk and EM Biglybt will not work without an actual install available with the path set in system path (and/or the java homes set).

DigitalDJ
02.04.20, 05:20
Biglybt+java from github installs and works without your mod applied


I understand that, and as I said previously....That installer works because the JRE is bundled and does not need to download the JRE. Something on your end is blocking the JRE download using the default BiglyBT installer. This has nothing to do with Java, AFAIK.

Nevertheless, it should not matter which installer you use. As long as BiglyBT is installed and runs.

The mod doesn't actually do anything to do with detecting Java. What detects Java on your system is the BiglyBT launcher (made by install4j). This is provided by BiglyBT, not us.

Uninstall your system-wide Java installs (don't do this manually, use the uninstallers). Remove any instances of Java from your PATH environment variable and unset JAVA_HOME.

Re-follow the instructions I provided to you to install the mod, instead using the BiglyBT+Java installer to install BiglyBT, seeing as that installer works for you.

Once you think you have the mod installed correctly, create a batch script on your desktop (e.g test.bat) containing the following (obviously replace the path to the correctly BiglyBT if that is not the correct location):



set INSTALL4J_LOG=yes
"C:\Program Files\BiglyBT\BiglyBT.exe"


Run the batch file, and then provide %TEMP%\i4j_nlog_1.log file that will be generated.

From there, we can debug what is wrong with your setup.

JP2020
02.04.20, 10:32
I understand that, and as I said previously....That installer works because the JRE is bundled and does not need to download the JRE. Something on your end is blocking the JRE download using the default BiglyBT installer.

Nevertheless, it should not matter.

The mod doesn't actually do anything to do with detecting Java. What detects Java on your system is the BiglyBT launcher (made by install4j). This is provided by BiglyBT, not us.


Yes
and BBT needs 1.8 and works hard to ensure it has that
and your stuff needs 13 - but "doesn't actually do anything to do with detecting Java"
BBT + EM reports its using biglybt\jre (13.2) when it seems clear at least part of it isnt - as detailed above.


The +java install of course leaves the java it used in temp along with loads of other stuff BBT (or your code) leaves lying around








Uninstall your system-wide Java installs (don't do this manually, use the uninstallers). Remove any instances of Java from your PATH environment variable and unset JAVA_HOME.

Re-follow the instructions I provided to you to install the mod, instead using the BiglyBT+Java installer to install BiglyBT, seeing as that installer works for you.

Once you think you have the mod installed correctly, create a batch script on your desktop (e.g test.bat) containing the following (obviously replace the path to the correctly BiglyBT if that is not the correct location):



set INSTALL4J_LOG=yes
"C:\Program Files\BiglyBT\BiglyBT.exe"


Run the batch file, and then provide the file %TEMP%\i4j_nlog_1.log file that will be generated.

From there, we can debug what is wrong with your setup.


You clearly haven't looked at how many times I've done that, and reported what happened
- just to be ignored (like others over the past 2 years) or bitched at
- and screwed up other working things in the process

I might consider doing that yet again when I have something worth doing it for.
I only referred the install as it seemed to point to possible related causes ...
and I was surprised no-one here had (or at least would share) the issue and resolution - so I worked at it




Already detailed above the error messages BBT-EM gives out above if it dont have an installed java, (the 13.2 copied java 'damaged' 'no JVM' - which makes no sense to me at all - redownload, re copied, and tried ones from openjdk - all same)

just like I and issue op in this thread stated that HTTP trackers know what client was being used before you asked to test with none HTTPS trackers and set up wireshark etc (which I do understand - but how has that helped other than prove we weren't lying - I see no solution)
Very limited (2/3) places these old trackers can and do get that from
client/ extended Client ID if they aren't the same anyway (user agent) or by interpreting the peerid.



We weren't talking about some detailed tracker analysis script here or close analysis by a human.


Step one
Sort out your instructions so repeated issues with consistent and accurate instructions can be stated - and set up a small test tracker (you must have one to test - just clone the minimum - should be 10 or 5 mins for someone working on that sort of stuff) that simply logs the connection data (and maybe writes it out as tracker error for the user) so you can see yourself what it claims
Rather than asking users to install/fuck about with/break their probably main machine.


You can get people to connect with any .torrent, with expected spoof client as the torrent name,
your ex's phone number or something else in the hash if you want to change it
and WhoGivesAShit what as the torrent data as its rejected anyway.


I don't doubt it is something to do with that e4j install process (as I have repeatedly said) which looks complete shite to me.

DigitalDJ
02.04.20, 11:42
Yes
and BBT needs 1.8 and works hard to ensure it has that
and your stuff needs 13 - but "doesn't actually do anything to do with detecting Java"


The mod is compiled with Java 13, and uses APIs only available in 13. Without it, it does not work. There's no code that "checks" for Java 13, things will just fail if Java 13 is not used.



BBT + EM reports its using biglybt\jre (13.2) when it seems clear at least part of it isnt - as detailed above.


If BiglyBT + EM is reporting Java 13.0.2, then it is using Java 13.0.2. There's no half-using Java, that's not a thing.



The +java install of course leaves the java it used in temp along with loads of other stuff BBT (or your code) leaves lying around


Whatever code we have, doesn't mess with installed JREs, it just uses them.

The BiglyBT+JRE installer does indeed leave a JRE in %TEMP%, but this is just a left over artifact of the installer. It is not used by BiglyBT, or the system. On my system, that folder is cleaned up when the installer exits. If you have the folder open when the installer exits, there's a possibility it sticks around because you have it open.



You clearly haven't looked at how many times I've done that, and reported what happened
- just to be ignored (like others over the past 2 years) or bitched at
- and screwed up other working things in the process

I might consider doing that yet again when I have something worth doing it for.
I only referred the install as it seemed to point to possible related causes ...
and I was surprised no-one here had (or at least would share) the issue and resolution - so I worked at it


Look. You can either listen and read, or not. If after this post, you can't provide detail I've asked for, you're on your own.

In my previous post I asked you to provide the a log when running BiglyBT, not the BiglyBT installer. This specific log file is not generated by default and is different to the log you provided.

When you previously provided a log to the BiglyBT installer I gave you a detailed analysis of what was going on. That was:

a) The installer is still detecting a system-wide Java 13 install, when I said multiple times to remove all system-wide installations -- as indicated by [0:150] checkJavaExe (C:\Program Files\AdoptOpenJDK\jre-13.0.2.8-hotspot\\bin\java.exe, [out], 4, 2, 0)

b) Since you don't have an appropriate Java version installed and using the non-bundled JRE installer, the installer does not find a compatible JVM since the version range is 1.8 to 1.11. As indicated by: [0:149] MinVersion: 1.8.0_172, MaxVersion: 1.11

c) The non-bundled installer is failing because it unable to download the JRE as indicated by line: [9:398] ERROR: InternetOpenUrl failed with error code 12157. I asked you to download a URL, as indicated by line [0:153] Download location: https://www.biglybt.com/jre/win64, in Internet Explorer, but you did not provide any results.




just like I and issue op in this thread stated that HTTP trackers know what client was being used before you asked to test with none HTTPS trackers and set up wireshark etc (which I do understand - but how has that helped other than prove we weren't lying - I see no solution)
Very limited (2/3) places these old trackers can and do get that from
client/ extended Client ID if they aren't the same anyway (user agent) or by interpreting the peerid.

We weren't talking about some detailed tracker analysis script here or close analysis by a human.


This right here is the crux of the problem. I asked for the information, and you did not provide it. You seem to think you know more about debugging the issue, but you don't.

a) Having the Wireshark capture helps indicate what is being sent to the tracker so we can identify what specific bit of information is making trackers identify BiglyBT instead of the spoof. As HBDB provided, it appears to be the User-Agent.

If you think this is just an exercise to determine if you're lying, you're delusional. If you had any idea about coding, you'd understand that now that we know it's the User-Agent, there are limited places in code where this could be occurring, and therefore identifying the underlying issue.

We literally pulled the attachment due to the reports here, even though I, and anon, were not able to reproduce the issue. Saying we're denying the issue is just bullshit. Getting an accurate reproducible instance of the issue is key to solving the problem. That includes proper installation, getting configuration dumps and packet captures.

b) There are multiple ways a tracker can determine the client, and it's more than what you have specified. It can be order of arguments, arguments sent by specific clients, order of tracker updates, nuances in HTTP headers. There's a reason why PerfectSpoof allows you to customize all these things.

c) We also, multiple times, asked you to provide your current Extreme Mod settings. Again, not to prove if you're lying, but to identify if a specific setting is causing the issue.




Step one
Sort out your instructions so repeated issues with consistent and accurate instructions can be stated


The step 1 of instructions will be clarified for the lowest common denominator. Nothing else. All other instructions are still accurate.



- and set up a small test tracker (you must have one to test - just clone the minimum - should be 10 or 5 mins for someone working on that sort of stuff) that simply logs the connection data (and maybe writes it out as tracker error for the user) so you can see yourself what it claims
Rather than asking users to install/fuck about with/break their probably main machine.


As others have stated. We're all volunteers here, we "work" for free. Testing every mod setting on every new BiglyBT version isn't feasible given my free time. If you think you have the time to test the features, you're more than to do that yourself, with your own local tracker. Either that, or start showing up the money.

JP2020
02.04.20, 13:26
yes yes
I have spent hours on this too despite sorting how to install it so it works except for the client id issue, yet I still persisted in trying to find the cause to help others who might get it as you ignore them.

- I was just initially hindered by acting your duff instructions, your limited and duff suggestions and (my error) not initially taking the EM patch out of the equation

You dont even state whether biglybt should be restarted after initial install before the patch although it seems reasonable to ASSUME not. It does try to update if you run it.






and although careful scripts can easily identify these spoof clients even if they are working properly, as I quickly saw (noted one to anon), as I said - my tests were on old http trackers with sod all in the way of scripts

and as you say, you should know far better than me what relationship client/client_id/user_agent have to each other in the spoofs ...


and what these sort of things do (once you accept they exist) created in the session today:

AppData\Local\Temp\e4j9FB2.tmp_dir1585749765\exe4j lib.jar
.. which is just some java shit to me.





I dont need the tracker to prove the issue - I thought it might help you.
BBT EM is no use to me without a spoof. Azureus is working fine.
I've only reinstalled to do some tests for someone else.



Oh - and don't forget that the onboard version spoof which the developers apparently disabled and you say you re-enabled (at some stage/version???) - DOES work

.. right up to the trackers

---------- Post Merged at 11:26 ---------- Previous Post was at 11:00 ----------

Oh and jdk vs jre for the normal people out there

Biglybt uses features which are in the JDK but not in the jre in things like swarm discovery and bigly messaging particularly PGP type stuff (keys).

So if you use jre rather than jdk there is some stuff that wont work - the full extent of which I'm not sure of.

DigitalDJ
02.04.20, 14:32
yes yes
I have spent hours on this too despite sorting how to install it so it works except for the client id issue, yet I still persisted in trying to find the cause to help others who might get it as you ignore them.


You claim "ignore", but again, people have lives. This isn't my life. Get over yourself honestly. This is not my job.



- I was just initially hindered by acting your duff instructions, your limited and duff suggestions and (my error) not initially taking the EM patch out of the equation


You're hindered by the many assumptions you make yourself. Many assumptions means red herrings. You do things to "solve" problems that are not part of the instructions.

I've given you so many straight instructions that you simply haven't followed since you constantly think it will make no difference. It's not my problem you don't have an IQ over 90.



You dont even state whether biglybt should be restarted after initial install before the patch although it seems reasonable to ASSUME not. It does try to update if you run it.


I don't even understand what you're saying here. Restarted after initial install?

The instructions state to install the latest BiglyBT release. If BiglyBT "updates" after you run it, it means it's updating plugins. They're allowed to update. That's not a problem. Even if you use an old installer and BiglyBT updates to say 2.4.0.0, once you copy over the mod, it will just revert back to 2.3.0.0. This is a non-issue. Literally, the entirety of the important code for BiglyBT is contained within one file - BiglyBT.jar

At least on Windows, you can't even replace the JAR while BiglyBT is running. Quite frankly, this mod isn't for a target audience of people with no technical expertise.



and although careful scripts can easily identify these spoof clients even if they are working properly, as I quickly saw (noted one to anon), as I said - my tests were on old http trackers with sod all in the way of scripts

and as you say, you should know far better than me what relationship client/client_id/user_agent have to


I don't know what in the fuck you're saying here. You're still not grasping the fact that without seeing what is sent to the tracker, it makes it difficult to guess what is causing the tracker to identify the client. Knowing that it's the User-Agent narrows the number of places the problem could be down to approximately 2 locations, rather than say quadruple that. Process of elimination is key.





and what these sort of things do (once you accept they exist) created in the session today:

AppData\Local\Temp\e4j9FB2.tmp_dir1585749765\exe4j lib.jar
.. which is just some java shit to me.


Temp is Temporary. Always. This is not a JRE, not a JDK. Not an installation of Java.



Oh and jdk vs jre for the normal people out there

Biglybt uses features which are in the JDK but not in the jre in things like swarm discovery and bigly messaging particularly PGP type stuff (keys).

So if you use jre rather than jdk there is some stuff that wont work - the full extent of which I'm not sure of.

Dear god this is some misinformation right there. Just use Google, jesus. How do you even come to this conclusion. I don't even understand how your brain works.

BiglyBT comes with the JRE.

The JRE is the Java Runtime Environment, the JDK is the Java Development Kit. The JDK contains the JRE and comes with additional developer tools, for compiling Java code.

BiglyBT does not need the JDK. The mod doesn't need the JDK. You don't get any extra features in BiglyBT, or the mod, for using the JDK over the JRE.

The only reason we use the JDK is because Oracle stopped distributing the JRE installer (binaries) for free after Java version 11. OpenJDK provides the latest Java binaries for free, and since the JDK also includes the JRE, we use it.

JP2020
02.04.20, 16:37
Dear god this is some misinformation right there. Just use Google, jesus. How do you even come to this conc

Because one of the bigly developers said it on the Bigly forum threads perhaps?
- quite clearly ...

So why are you pointing users at the JDK - which from your perspective there is just extra bloat for the users?

:rolling_eyes:

and now I've looked again, never ever ever seen a program leave so much shit lying about in the temp dir.
Dunno if thats the bigly code doing that ... or yours

DigitalDJ
02.04.20, 16:52
Because one of the bigly developers said it on the Bigly forum threads perhaps?
- quite clearly ...

:rolling_eyes:

and now I've looked again, never ever ever seen a program leave so much shit lying about in the temp dir.
Dunno if thats the bigly code doing that ... or yours

Please link such thread. Your history here shows you seem to have trouble interpreting things you?re not familiar with. I am certain that using the JDK in place of the JRE offers no benefit to BiglyBT and I have absolute confidence in the BiglyBT developers to not have made such an absurd statement.

I literally explained to you why we point to the JDK. Just more evidence you literally do not read. Yes, you could pick out just the JRE components from the OpenJDK zip file, but considering we have users that apparently have trouble extracting said zip file to a folder....hmmm.....

Install4j is what creates files in Temp, and they get cleaned up after installers or BiglyBT exits, as long as something is not preventing them from being deleted. Code is neither related to the mod, or BiglyBT, just another irrelevant thing to bitch about. Vuze uses an older version of the same god damn launcher.

Sazzy
02.04.20, 21:17
I can confirm that the only extras the JDK offer are things like javac (compiler), javadoc, jdb (debugger), ...
So basically the JDK offers nothing for running programs. Unless they're using anything under javax.tools, (like generating and compiling code at runtime), which seems highly unlikely to me. Let alone anything useful for users.

edit: Found a nice overview:

20346


JDK is a superset of JRE, and contains everything that is in JRE, plus tools such as the compilers and debuggers necessary for developing applets and applications. JRE provides the libraries, the Java Virtual Machine (JVM), and other components to run applets and applications written in the Java programming language.

JP2020
02.04.20, 21:51
Now I realise that this actually may seem and actually be a stupid question .. I don't know but:

The 13.2 installed java I have has both client and server dirs in \bin
The Windows/64 one on the linked page (which I keep copying in) only seems to have server
http://jdk.java.net/13/


That an issue?



(I have re-downloaded it a few times over the past week and again just now)

DigitalDJ
03.04.20, 02:23
That an issue?


Nope. Link is correct, zip still valid.

JP2020
04.04.20, 00:17
Not for me

minor change made to bring it in line with what you say is 'right' and it all went tits up again - so uninstalled ... again.


Went to v1.8 and apart from the inline stub install failing on fetching the java (which azureus fetched with no issues in 2 versions earlier today) requiring me to use the +java installer
... all went fine. No needing to 'fuck around' with anything. No java erors - just worked with a java 9 extract replacing the install jre.

Not checked spoofing yet

DigitalDJ
04.04.20, 05:53
Not for me

minor change made to bring it in line with what you say is 'right' and it all went tits up again - so uninstalled ... again.


Went to v1.8 and apart from the inline stub install failing on fetching the java (which azureus fetched with no issues in 2 versions earlier today) requiring me to use the +java installer
... all went fine. No needing to 'fuck around' with anything. No java erors - just worked with a java 9 extract replacing the install jre.

Not checked spoofing yet

Either provide the log I asked for to troubleshoot the issue or stop bitching.

--->HDBD<---
04.04.20, 09:32
@JP2020
I don't know what problems they have with java you are trying all kinds of versions
what exactly is your problem Java, BiglyBT, Perfect Spoof.

eragooo
04.04.20, 12:40
Everything is working fine for me. No problem at all. Both Windows and Mac OS.

JP2020
04.04.20, 20:27
@JP2020
I don't know what problems they have with java you are trying all kinds of versions
what exactly is your problem Java, BiglyBT, Perfect Spoof.


Summary

I had a working age old azureus+EM with working spoof - a couple of minor issues which were documented but no real issue to me so had been using it for years

Thought - lets try biglybt, its 64 bit so shouldn't even affect my 32 bit working Az



Saw line one of instructions didn't seem to make sense, read through the threads, saw various responses so installed a 13.2 java linked by someone else referring this in the threads

Tried to install bbt 2.2.0.2 - the first bigly I had installed
It failed trying to download the java - still does this with BBT installs - does NOT do this for azureus installs

Tried copying extracted contents of linked file into biglybt\jre folder thinking that I had misunderstood
Still the install failed.
Tries a few other things, none of which should make any difference just as my installing a java shouldn't have done anything but enable it

Went round the circuit a few times and eventually found the biglybt+java install - which worked.

For some reason the 'do you want to start bbt option didn't come up - it just restarted
It started ok - IT did some downloading - then when it seemed to have stopped doing stuff
I shut it down and then deleted the biglybt\jre and copied the extracted linked jdk into biglybt and renamed it jre (yes the right level folder)

started biglybt from the created shortcut - java errors
I thought 'fuck this' and tried to fire up my old azureus - it wouldn't start.
So it was a choice between uninstalling everything and a fresh run at the old azureus or persist a bit
I chose wrong


Then round the circuit a few more times 'fucking around with java' sand asking questions here as so many others have before trying to get it to start - it eventually did but ONLY with an installed java and the system path set to that installed java

Some stability issues - and you raised the spoof issue

Dickwad says its my 'fucking around with java - none of which apart from setting the installers system variable should have made any real let alone negative impact on the bbt running
You have a java install if I read your java list correctly as does loads of people
I almost ceratinly ended up with LESS java in my system than almost everyone.

- but I listened and tries all sorts including uninstalls and a deep scan and removal of all java and install of 2.3+java after uninstall of 2.2.0.2 - breaking other things - yet they were working and tidy installs

Got it working but with stability issues and no spoof


It gave the impression of 2 different programs doing stuff in tandem - but there was not 2 instances as far as I could see.

Installed old azureus from scratch - no issues with install including its inline download of java/whatever


What I HAVE seen since
is crap left in the temp folder as despite the log showing bbt issuing deletes for the temp files - they remain
A core_BiglyBT2.2.0.2.jar appearing in temp (looks like a torrent download by biglbt which I knew nothing about) dated after I had unistalled that version and installed 2.3.0.0
Deleted the lot from appdata\local\temp (not suggested as to be deleted unlike the roaming folder which loses everything.




So just uninstalled it all yet again, including the az, bigly + java ... again
Went to the latest bigly version pre 2.x with a +java installer on github - which is 1.8
Installed fine
Copied the referred version extracted code just as I did first time with 2.2.0.2 - fine
Started fine
Working fine so far apart from spoof client id/user agent not working - and only downloading it and tried once for success - not many times like with 2.2 and 2.3

So I'll do what I agreed I would (now I can) and then fuck this.
Simply seems pointless saying what I see to have some arsehole step sideways on it and say I'm not doing what I am doing and not seeing what I am seeing
.. just like he has so many times before to others

DigitalDJ
05.04.20, 09:31
- but I listened


Bitch please, you hypocrite. You wonder why I ignore morons around here. You're the reason. Time in my life is better spent not replying to people like you.

You haven't done a single thing I asked you to do to troubleshoot or debug either the PersectSpoof, or your Java installation issues.

JP2020
07.04.20, 12:07
LOL
and you still haven't even corrected that first line despite spending shitloads of time doing anything you can to point the finger elsewhere
Twat


Note to self

Its fckn obvious that install as a first step means copy at a later step now isnt it

and that simply installing a stated version of java for a java program (which many will probably already have installed anyway) is not only a stupid assumption, it is 'fucking around with java' and will break things

I mean, who would assume you should install java, as a first requirement for a java program, simply based on some demonstrable arsehole simply stating that as a requirement for little more than a few years concurrent.

Silly me.

Can't be arsed to link all the arrogant, useless shit you've thrown at people with issues (including this issue) through the releases and over the years
Thought about it but not sure if theres a limit on post length it would break.


and thats even before you get to: should you allow the bigly install to restart and update or not
- despite that being included in patches since longer than most here were born.



and thats before you use/compile with a later version of java than the program very successfully uses


and thats before you use a version apparently with closed code rather than one of the quality iopenjdks

and thats before telling users to copy/install/shove up your ass jdk bloat rather than jre

the list does go on.


Bit of a numpty really aren't you?

--->HDBD<---
07.04.20, 12:52
So please, stop insulting

DigitalDJ
07.04.20, 14:24
Its fckn obvious that install as a first step means copy at a later step now isnt it

and that simply installing a stated version of java for a java program (which many will probably already have installed anyway) is not only a stupid assumption, it is 'fucking around with java' and will break things


Clarified the step for you multiple times, and you still kept installing Java. You can install Java if you like. As I said, once extracted to the "jre" folder, the install4j launcher will always use the JRE in that folder over a system install.



and thats even before you get to: should you allow the bigly install to restart and update or not
- despite that being included in patches since longer than most here were born.


Also clarified this for you. It doesn't matter if you let BiglyBT update after installing the latest version. The only updates will be plug-in updates which do not affect the mod.



and thats before you use/compile with a later version of java than the program very successfully uses


We do this because the implementation PerfectSpoof modifies the HttpURLConnection code from the Java API. Therefore, to keep this code current and patched with security issues, we use the HttpURLConnection code from the latest Java release.



and thats before you use a version apparently with closed code rather than one of the quality iopenjdks

and thats before telling users to copy/install/shove up your ass jdk bloat rather than jre


Closed code? What? I explained this to you. Do you ever read anything?

What about "OpenJDK" seems closed to you? We literally use OpenJDK because it is free and open-source. The whole reason we have to use the OpenJDK, and not JRE, is because Oracle no longer provides binary JRE redistribution for free.

OpenJDK is the completely open-source reference Java implementation.

If you're going to claim ~50MB is "bloat" on modern systems, you've got problems. If you want to strip down the JDK to just the JRE, you are more than welcome to in your own time.



Bit of a numpty really aren't you?


Thanks to HDBD's data, we've solved the PerfectSpoof issue.

anon
08.04.20, 09:20
Since the attachment in this thread has been removed and a fixed build of 2.3.0.0 is now available (34551), I think we can lock this.