Help inter process communication

15 Oct 2013
265
43
#1
Heyo Freunde,

kurz und knapp, ich bräuchte Hilfe dabei ein Bytearray aus einem C# Programm nach außen zu tragen, ohne System.Net.Sockets und ohne System.IO namespaces.

Gibt allerdings ein paar Probleme hierbei. Es geht hier, um mal auszuholen, um das Pluginsystem des Diablo3 Cheats/Overlays TurboHUD.
Es gab vor einer Weile ein Automation Tool, das basically nur ein advanced Macro ist um Skills auf cooldown zu casten etc. Dieses.
Das ganze hat so funktioniert, dass TurboHUD eben Plugins, geschrieben in C# lädt und mit ausführt.
So hat der creator dieses Tools bisher alle nötigen Infos durch die TurboHUD "SDK" gesammelt und durch Netsockets über einen TCP stream zur verfügung gestellt, mit einem C++ Client ausgelesen und darüber die Macros ausgeführt. Hat soweit auch geil funktioniert.
Der Creator hat sich jetzt aber gegen automation gestellt und die beiden namespaces gesperrt.

Ich habe schon einen workaround der allerdings nicht sehr performant ist und manchmal etwas laggen kann.
Wollte nun fragen ob ihr andere Ideen habt, ich weiß leider nicht mehr genau weiter. Pipes undso sind halt leider gesperrt....

Mit freundlichen Grüßen

Edit: Hatte auch schon die Idee THUD zu entpacken und die Sperre aufzuheben, ist aber mit irgendeiner custom ConfuserEx Version protected, und ich bin kein Profi was reversing betrifft lul
 

Dr_Pepper

Active Member
11 May 2013
105
205
#5
Gibts irgendwelche Infos dazu wie dieser block funktioniert?
Wird vor dem laden deines Plugins geprüft welche libs verwendet werden oder wird das irgendwie zur runtime verhindert?

Kannst du unsafe Code verwenden? Kannst du C# Module dynamisch nachladen?
 
15 Oct 2013
265
43
#6
Gibts irgendwelche Infos dazu wie dieser block funktioniert?
Wird vor dem laden deines Plugins geprüft welche libs verwendet werden oder wird das irgendwie zur runtime verhindert?

Kannst du unsafe Code verwenden? Kannst du C# Module dynamisch nachladen?
Bisher nur durch ausprobieren.
Wenn innerhalb des Plugins ein unerwünschter namespace bzw Zeile, wie dllimport, gefunden wird, wird das plugin nicht compiled.
Bisher denke ich, dass das der einzige weg ist wie sowas versucht wird zu detecten.

C# kann ich leider nicht sonderlich gut bzw hab kaum erfahrung. Habe davon noch nichts gehört und dementsprechen noch nciht ausprobiert.

Edit: Gute Idee, geht leider nicht, System.Reflection ist ebenfalls gesperrt. Schade.
 
Last edited:

thepapanoob

Well-Known Member
22 Oct 2015
367
367
#8
Bisher nur durch ausprobieren.
Wenn innerhalb des Plugins ein unerwünschter namespace bzw Zeile, wie dllimport, gefunden wird, wird das plugin nicht compiled.
Bisher denke ich, dass das der einzige weg ist wie sowas versucht wird zu detecten.

C# kann ich leider nicht sonderlich gut bzw hab kaum erfahrung. Habe davon noch nichts gehört und dementsprechen noch nciht ausprobiert.

Edit: Gute Idee, geht leider nicht, System.Reflection ist ebenfalls gesperrt. Schade.
lade die c# dll manuell nach ohne und call den reflection kram :grin: (also die native davon)
 
15 Oct 2013
265
43
#11
Wenn du deinen Workaround erklärst könnte man helfen den zu optimieren
War übers Clipboard, gab wenig zu optimieren, war an sich n relativ schlechter Weg.

du sollst deine c# assembly manuell laden (alloc & wpm) und dann reversen was system.reflection macht um c# dlls zu laden. um das dann nachzubauen / native zu callen
Stimmt könnte klappen, allerdings hab mit mit der top Hilfe von Dr_Pepper Dr_Pepper bereits etwas gefunden, funktioniert 1A.

Dennoch Danke an die Anderen