C# decompiler yields Unicode named classes/functions...
-
Okay, turns out that my approach to talking to my Physics measuring tools directly using USB packets is taking a bit too much time. I mean, yes, I am perfectly able to get there eventually but there are a lot of intricacies to consider and I'm usually loathe to re-invent the wheel.
The developer of the software also provides an API which targets .NET 2.0, the compiled DLL works fine in WPF and console projects.
I however, want to use the WinRT API for the single reason that I then could use Hosted Web Apps which would then enable me to put the main application code on a webserver. Thus, whenever I'm updating the app, I only need to update the webserver's code once.
The other way would require me to give the update to someone else, hope that he deploys the update in a timely fashion (minimum: One week) and also hope that the update actually reaches each of the 25 Surfaces we have.So, re-inventing the wheel is stupid. The DLL is there. However, it's not a pure DLL in the sense of: "I'll give you some functions to call which then talk to the devices which in turn return some data!", no, it's a DLL in the sense of "Everything and the kitchen sink!"
Which means that there's code in there which calls
System.Drawingand other assorted namespaces in order to draw not-so-pretty pictures of the hardware modules.So I thought to myself to have a look and use a Decompiler to see how to work around this stuff. I tried dotPeek and dnSpy, the latter of which actually showed me the problem itself (instead of showing empty strings):
So, any hints for me on how to proceed?
-
@Rhywden Why not do a 'Hosted Web App' type thing in WPF instead? Is there a specific reason to use WinRT?
-
Wait, what? All \uXXXX characters you're seeing are illegal in C# identifiers (they're control codes, or maybe whitespace).
-
Sounds like it's been run through an obfuscator, specifically to dissuade things like what you're doing.
We used one at my last job and this is the sort of thing that happened when you tried to decompile
-
@Jaloopa said in C# decompiler yields Unicode named classes/functions...:
Sounds like it's been run through an obfuscator, specifically to dissuade things like what you're doing.
We used one at my last job and this is the sort of thing that happened when you tried to decompile
Yes, but the weird thing is that, as you can see from the screenshot, only a minor percentage would be obfuscated - I mean, there are plenty of plaintext comments in there, explaining what the code does.
-
@RaceProUK said in C# decompiler yields Unicode named classes/functions...:
@Rhywden Why not do a 'Hosted Web App' type thing in WPF instead? Is there a specific reason to use WinRT?
Because, um, HWA only exist for WinRT? Yes, WPF probably has a WebView (didn't bother to look) but it definitely hasn't the capability of giving the WebView's content access to the app's (and thus the client's) capabilities.
-
@Rhywden My apologies. It appears my clairvoyance unit malfunctioned and failed to inform me you needed HWA-specific features.
-
@RaceProUK said in C# decompiler yields Unicode named classes/functions...:
@Rhywden My apologies. It appears my clairvoyance unit malfunctioned and failed to inform me you needed HWA-specific features.
I wrote as much in the initial post.
-
@Rhywden said in C# decompiler yields Unicode named classes/functions...:
@Jaloopa said in C# decompiler yields Unicode named classes/functions...:
Sounds like it's been run through an obfuscator, specifically to dissuade things like what you're doing.
We used one at my last job and this is the sort of thing that happened when you tried to decompile
Yes, but the weird thing is that, as you can see from the screenshot, only a minor percentage would be obfuscated - I mean, there are plenty of plaintext comments in there, explaining what the code does.
Obviously things like summary tags and actual public property names can't be obfuscated - you'll be using those from the application that calls the library. The privates are fair game.
You can probably consistently search-and-replace those wacky identifiers with something sensible.
-
@Rhywden I guess you've already ruled out writing a Web API instead of a website, and having the app talk directly to the API, therefore bypassing the need for a HWA.
The only other remotely practical solution I can think of right now is a native app with that DLL that communicates with the HWA via some form of IPC, but given the HWA is in WinRT, I get the feeling IPC is out of the question. Plus, you'd have two apps instead of one, and that's just dumb.
Looks like you're stuck with reverse-engineering and search-replacing those obfuscated members. Unless there's a WinRT-compatible library, but then again, the fact you're reverse engineering likely means there isn't one.
-
@RaceProUK A WebAPI would be way too slow - the roundtrip to the server and back to the client would make several applications I'm thinking of either largely unusable or would force me to update the client's portion of the app with every code change which would in turn annihilate the argument for the server-client architecture.
-
try this?
-
@Rhywden I wrote a WPF app and distribute it using ClickOnce. It's a very simple app so I don't know what WTFs ClickOnce may hold for more serious projects, but there is a big upside. I just upload the binary and the VS generated assorted XML to some FTP server, and whenever any user starts the already installed app on their PC, if they're online there is an automatic check for update and it gives them an option to update with one click.
-
@marczellm said in C# decompiler yields Unicode named classes/functions...:
@Rhywden I wrote a WPF app and distribute it using ClickOnce. It's a very simple app so I don't know what WTFs ClickOnce may hold for more serious projects, but there is a big upside. I just upload the binary and the VS generated assorted XML to some FTP server, and whenever any user starts the already installed app on their PC, if they're online there is an automatic check for update and it gives them an option to update with one click.
Due to the way our Surfaces are configured to wipe the disc after shutdown, this would require users to go through that procedure after every boot.
-
@Rhywden said in C# decompiler yields Unicode named classes/functions...:
Due to the way our Surfaces are configured to wipe the disc after shutdown
Guess if you want to do anything, you don't shut down often... WAIT!!!! STOP!!! Dammit Windows Update!!!
-
@Maciejasjmj said in C# decompiler yields Unicode named classes/functions...:
@Rhywden said in C# decompiler yields Unicode named classes/functions...:
@Jaloopa said in C# decompiler yields Unicode named classes/functions...:
Sounds like it's been run through an obfuscator, specifically to dissuade things like what you're doing.
We used one at my last job and this is the sort of thing that happened when you tried to decompile
Yes, but the weird thing is that, as you can see from the screenshot, only a minor percentage would be obfuscated - I mean, there are plenty of plaintext comments in there, explaining what the code does.
Obviously things like summary tags and actual public property names can't be obfuscated - you'll be using those from the application that calls the library. The privates are fair game.
You can probably consistently search-and-replace those wacky identifiers with something sensible.
I agree. Those are probably private member methods and objects. I'd guess the numerics are indices into
this's table of member items in memory.
-
@Rhywden said in C# decompiler yields Unicode named classes/functions...:
@marczellm said in C# decompiler yields Unicode named classes/functions...:
@Rhywden I wrote a WPF app and distribute it using ClickOnce. It's a very simple app so I don't know what WTFs ClickOnce may hold for more serious projects, but there is a big upside. I just upload the binary and the VS generated assorted XML to some FTP server, and whenever any user starts the already installed app on their PC, if they're online there is an automatic check for update and it gives them an option to update with one click.
Due to the way our Surfaces are configured to wipe the disc after shutdown, this would require users to go through that procedure after every boot.
-
@sloosecannon said in C# decompiler yields Unicode named classes/functions...:
@Rhywden said in C# decompiler yields Unicode named classes/functions...:
@marczellm said in C# decompiler yields Unicode named classes/functions...:
@Rhywden I wrote a WPF app and distribute it using ClickOnce. It's a very simple app so I don't know what WTFs ClickOnce may hold for more serious projects, but there is a big upside. I just upload the binary and the VS generated assorted XML to some FTP server, and whenever any user starts the already installed app on their PC, if they're online there is an automatic check for update and it gives them an option to update with one click.
Due to the way our Surfaces are configured to wipe the disc after shutdown, this would require users to go through that procedure after every boot.
I'm sure he didn't mean wipe the disks like that. More like revert changes to approved snapshot (I'm thinking Windows SteadyState).
-
@Rhywden Did you try contacting the author? He may send you a normal dll if you ask nicely.
-
I suggest you to try open the DLL using ildasm.exe and see if you still see the same thing.
Somehow I think the decompiler might have a problem with those attributes. Or the DLL is written in managed C++ and the decompiler don't know how to handle those CPPImplementationDetails.
