PerfectSpoof does not work for bit-hdtv.com
Attachment 20340
Attachment 20341
the same on hdbits.org
Printable View
PerfectSpoof does not work for bit-hdtv.com
Attachment 20340
Attachment 20341
the same on hdbits.org
Hmm HTTP vs HTTPS. Gives me some idea where to look. Thanks.
You don't happen to be using a proxy?
No, I do not use proxy.
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".
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.
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.
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 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).
2. Download and install the latest non-beta BiglyBT release (BiglyBT - 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) 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"
9. Run BiglyBT and Enjoy!Code:--patch-module=java.base=ghostfucker_utils.jar
--add-exports=java.base/sun.net.www.protocol=ALL-UNNAMED
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.
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.
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.
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.
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).
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):
Run the batch file, and then provide %TEMP%\i4j_nlog_1.log file that will be generated.Code:set INSTALL4J_LOG=yes
"C:\Program Files\BiglyBT\BiglyBT.exe"
From there, we can debug what is wrong with your setup.
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
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.
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.
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.
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.
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.
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.
The step 1 of instructions will be clarified for the lowest common denominator. Nothing else. All other instructions are still accurate.
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.
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.