Path Change of Unbroken.LaunchBox.Plugins.dll

[Lahma]

So when y'all switched over to .NET Core, 'Unbroken.LaunchBox.Plugins.dll' was moved from the 'Metadata' directory to the 'Core' directory. Besides the Plugin API webpage not mentioning this change, all plugins that reference this DLL must be updated to point to this new path or compiling fails. Obviously it's not a big deal, but it would probably be helpful to new developers if you at least update the plugin documentation. Also, just as an aside, any plugins that get the LaunchBox directory by using something such as 'Path.GetDirectoryName(Path.GetFullPath(Assembly.GetEntryAssembly()))' are also broken by the new update as this now resolves to the 'Core' directory instead of the base LaunchBox directory. Again, not a huge deal, but I just thought I would mention it in case anyone else is having problems.

Edit: I'm also now seeing this warning whenever compiling my plugin (after LB moved to .NET Core):
Found conflicts between different versions of "System.Drawing.Common" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed.
Does not appear to be causing any problems at the moment though.

 

Edited September 8, 2020 by Lahma

[Lahma]

Now another new problem... Whenever I try to debug my plugin now in Visual Studio 2019, I cannot set LaunchBox.exe as the debug application. It throws an error about it being a .NET Core application and my code being .NET Framwork. If I instead try to open LaunchBox and then attach to it with the VS2019 debugger, LaunchBox itself detects the debugger and closes the process (really? anti-debugger in an application that supports plugins?). This whole "upgrade" to .NET Core has been an absolute disaster for my plugin development which I've easily spent probably half a thousand hours on. Maybe I'm alone in this.. I don't know. It would be great to hear a response from @Jason Carr or @neil9000 and maybe some advice how to proceed? Seems this upgrade to .NET Core was maybe done too quickly without giving any thought to the developers who have spend thousands of hours developing plugins for your application. I've personally heaped nothing but praise on your application and have been personally responsible for probably half a dozen people or more buying licenses, but I'm just starting to get a bit worn out trying to deal with the many, many issues that have arisen since this major change implemented in 11.3. Can you please at least remove the anti-debugger code in your app so I can at least try to debug my plugin without having to resort to using dnSpy or some other app that will allow me to use driver-level anti-debugger bypass features?

[JoeViking245]

If you setup your debugger to copy the compiled dll over to the Plugins folder, then launch D:\LaunchBox\LaunchBox.exe, the debugger will exit as soon as the LB exe file exits.  Which will pretty much be right away as that exe redirects to LaunchBox.exe in the Core folder, thus exiting itself.  Not an anti-debugger.  The program exited. "Simple fix"... set the debugger to launch the exe in the Core folder.

Problem now is an innate [default] limitation of Visual Studio of debugging a NET Framework class library through a NET Core application.  If you look around, there is a way to 'tell your debugger' that you want to debug your library through a NET Core application, and you can get it to work.  At least according to the folks on Stack Overflow.   

[Jason Carr]

@Lahma Sorry for the added difficulty for plugins with the 11.4 release. I understand the frustration. I do wish the .NET Core upgrade had been a smoother experience, but I still feel that it was necessary, even with it being the major challenge that it was.

Thanks for those helpful notes @JoeViking245. Let us know if they help you get back up and running @Lahma.

[Lahma]

On 9/9/2020 at 10:52 AM, Jason Carr said:

@Lahma Sorry for the added difficulty for plugins with the 11.4 release. I understand the frustration. I do wish the .NET Core upgrade had been a smoother experience, but I still feel that it was necessary, even with it being the major challenge that it was.

Thanks for those helpful notes @JoeViking245. Let us know if they help you get back up and running @Lahma.

Thanks for responding to my post @Jason Carr. Unfortunately @JoeViking245s post wasn't helpful. He didn't understand what I was talking about. I can show the anti-debugger code in Unbroken.LaunchBox.Windows.dll in Dnspy. This has nothing to do with the Visual Studio problems. Obviously you can give more info than I can about the circumstances under which it is triggered, but no, this has nothing to do with the LaunchBox launcher executable exiting after launching LaunchBox.exe in the Core directory. I'm launching LaunchBox using "dotnet exec LaunchBox.dll" inside of the Core directory. Here is the anti-debugger code I am referring to:

// eJ8pBAv9gAr1FwnyGOP.cXM0gavBtCyXsWVqWP5
// Token: 0x06002E21 RID: 11809 RVA: 0x001521BC File Offset: 0x001503BC
internal static void rkhvpo29Ec0()
{
	if (Debugger.IsAttached)
	{
		throw new Exception("Debugger Detected");
	}
}

I'm not an amateur programmer. I'm aware that you can attach a debugger to a .NET Core process inside of a .NET Framework project by clicking "Attach to Process" and selecting "Managed (CoreCLR)" as the code type, but doing that causes the anti-debugger code listed above to be triggered and causes the LaunchBox process to exit. PLEASE do something to resolve this Jason. I would like to be able to fix my plugin and get a working version out to the many people who are waiting to use it again. Thanks for your help man.

Edited September 13, 2020 by Lahma

[Lahma]

On 9/9/2020 at 8:40 AM, JoeViking245 said:

If you setup your debugger to copy the compiled dll over to the Plugins folder, then launch D:\LaunchBox\LaunchBox.exe, the debugger will exit as soon as the LB exe file exits.  Which will pretty much be right away as that exe redirects to LaunchBox.exe in the Core folder, thus exiting itself.  Not an anti-debugger.  The program exited. "Simple fix"... set the debugger to launch the exe in the Core folder.

Problem now is an innate [default] limitation of Visual Studio of debugging a NET Framework class library through a NET Core application.  If you look around, there is a way to 'tell your debugger' that you want to debug your library through a NET Core application, and you can get it to work.  At least according to the folks on Stack Overflow.   

Hey @JoeViking245, just wanted to say I appreciate you offering the advice you gave. While it wasn't relevant to the problems I'm having, I didn't mean to disregard your post in my previous msg. I suspect it will be useful to other plugin devs who are trying to update their plugins to work with the .NET Core LB update, as everything you said is definitely one of the first problems one is going to have to work through. Anyways, I just wanted to apologize if I came across as an ass.. Definitely didn't mean to disregard your advice.

[JoeViking245]

No offense taken.  I was stuck looking at the 'left hand', while you were simply talking about the 'right hand'.  They do connect in the middle, just sit on opposite sides. lol   It's all good.

[Jason Carr]

@Lahma We were forced recently to change obfuscators because of some recent piracy issues. I wasn't aware that it would prevent debugging of plugins. I'll look to see if there's anything I can do here to resolve that. I assume that previous versions of LaunchBox did not have this issue?

[Lahma]

5 minutes ago, Jason Carr said:

@Lahma We were forced recently to change obfuscators because of some recent piracy issues. I wasn't aware that it would prevent debugging of plugins. I'll look to see if there's anything I can do here to resolve that. I assume that previous versions of LaunchBox did not have this issue?

Hey @Jason Carr, no, there were never any problems debugging plugins until the change to .NET Core. Being a reverse code engineer by trade, with .NET being one of my primary areas of focus, I would be happy to speak with you in further detail by PM so I can provide more details. I assume you would probably prefer me not speak about the details of LB's security/obfuscator/disassembly in a public thread, so I won't mention any specifics unless I hear from you via PM. One thing I will say however is that having anti-debugger code is not providing your software any extra security, at all. Essentially every publicly available .NET debugger/decompiler have built-in settings which allow you to patch, on-the-fly, the various, normally used methods, for detecting an attached debugger (which I can confirm bypass the System.Diagnostics.Debugger.IsAttached method).

[Jason Carr]

11.5 is out now (we were planning on releasing today anyways). I believe it will fix this issue @Lahma.

[Lahma]

That was quick! Thanks alot @Jason Carr. I will check it out ASAP.

[eyrie0]

Hi, I am getting this same error when trying to debug my plugins.  An exception of "Debugger Detected" is thrown on launch of Core/LaunchBox.exe from Visual Studio.  Is there any workaround for this?  It's basically impossible to develop plugins without being able to debug them!

[Jason Carr]

On 1/1/2021 at 1:19 PM, eyrie0 said:

Hi, I am getting this same error when trying to debug my plugins.  An exception of "Debugger Detected" is thrown on launch of Core/LaunchBox.exe from Visual Studio.  Is there any workaround for this?  It's basically impossible to develop plugins without being able to debug them!

This was an issue specifically with 11.8. The latest betas (and the new official 11.9 version which is coming out soon) won't have this problem.