I’m using Intellilock in order to obfuscate and lock my SW.
I tried to use “simple” obfuscation options with following params:
and when decompiling the code (using JetBrain.dot peek) I got the following code:
Since the code IS runnable and since any idiot can understand that the second parm is the password – a breakpoint gives us the password which the SW uses in order to encrypt some files.
So I tried to check the two circled checkboxes (public types/all parameters). When Opening JetBrain.DotPeek – the result is fantastic – nothing is understandable.
But now the SW doesn’t open at all….
When looking into windows event viewer I get the following log:
.
Which means the static main couldn’t start even…
Any simple guidlines for how to normaly obfuscate my code?
Thanks!
So - I got a reply from IntelliLock support.
Obfuscating a public class requires obfuscating all dlls calling this class, such that all will get the new, obfuscated name.
So just adding all dlls is required.
I'm not sure yet [and will update hopefully] if skipping ignoring them will be sufficient.
Related
I am new to Salesforce apex coding. My first class that I am developing has 10 methods and is some 800 lines.
I haven’t added much of exception handling, so the size should swell further.
I am wondering, what the best practice for Apex code is... should I create 10 classes with 1 method instead of letting 1 class with 10 methods.
Any help on this would be greatly appreciated.
Thanks
Argee
What do you use for coding? Try to move away from Developer Console. VSCode has some decent plugins like Prettier or Apex PMD that should help you with formatting and making methods too complex. ~80 lines/method is so-so. I'd worry about passing long lists of parameters and having deeply nested code in functions rather than just their length.
There are general guidelines (from other languages, there's nothing special about Apex!) that ideally function should fit on 1 screen so programmer can see it whole without scrolling. Read this one, maybe it'll resonate with you: https://dzone.com/articles/rule-30-%E2%80%93-when-method-class-or
I wouldn't split it into separate files just for sake of it, unless you can clearly define some "separation of concerns". Say 1 trigger per object, 1 trigger handler class (ideally derived from base class). Chunkier bits not in the handler but maybe in some "service" style class that has public static methods and can operate whether called from trigger, visualforce, lightning web component, maybe some one-off data fix would need these, maybe in future you'd need to expose part of it as REST service. And separate file for unit tests (as blasphemous as it sounds - try to not write too many comments. As you're learning you'll need comments to remind yourself what built-in methods do but naming your functions right can help a lot. And a well-written unit test is better at demonstrating the idea behind the code, sample usage and expected errors than comments that can be often overlooked).
Exception handling is an art. Sometimes it's good to just let it throw an exception. If you have a method that creates Account, Contact and Opportunity and say Opportunity fails on validation rule - what should happen? Only you will know what's good. Exception will mean the whole thing gets rolled back (no "widow" Accounts) which sucks but it's probably "more stable" state for your application. If you naively try-catch it without Database.rollback() - how will you tell user to not create duplicates with 2nd click. So maybe you don't need too much error handling ;)
We use obfuscation jar in our build and we use Log4j2 for logging purpose. However, the informative logs which we are logging as a string are being logged correctly. But, the logs in case of exception, i.e. the trace of exception or exceprion.getmessage() doesnot print the details. That too comes in obfuscated form, i.e. its not readable.
Any suggestions to overcome this problem?
That sounds like expected behaviour...
At runtime, class names and package names are scrambled, so stack traces may not look pretty.
Does your obfuscator not have a de-obfuscate function? I imagine it would generate a file with meta-data (mapping between cleartext names and scrambled names) when it does the scrambling.
If your users then have an issue they need support for, they send you their (scrambled) stack trace. You can unscramble that stack trace and make it readable again by using that meta-data file. (You should keep one for every version of your library that you publish.) That's how you would deal with support issues.
You are probably initializing your loggers like this:
Logger logger = LogManager.getLogger(MyClass.class.getName());
This way is useful during development when you rename / refactor your code a lot. But once you are satisfied with your code you should replace that line with a constant name like this:
Logger logger = LogManager.getLogger("my.package.MyClass");
This way the class name - i.e. logger name - wouldn't be obfuscated.
I'm posting this to basically continue a thread that was closed:
"Error trying to open a VS 2010 project in VS 2012 : Type universe cannot resolve assembly" by user1766173
I've dug deeper into the issue and narrowed some things down, so hopefully the discussion can be resumed.
I'm using VS 2012 (and I don't have 2010 to compare to). My solution, "TWConsole", was working fine on Friday, and as of Tuesday it was not. Both versions compile and run fine, but in the designer, no XAML file in the project can be opened without crashing. However, opening an XAML from a different project within the same solution works fine. Everything I've googled regarding this issue results in someone dealing with a 3rd party assembly.
However, in my case the assembly that can't be resolved is my own--the one generated by the build.
Interestingly, I've found that by "secretly" replacing the TWConsole.exe in the bin\Debug folder with from last monday's build, everything works! ... that is, until I rebuild the solution, and that exe gets replaced, and then the XAML designer begins crashing.
So there's something relating to new code I've added that is somehow "infecting" the main assembly. In the meantime before anyone can come to my rescue with a solution, I will start with the last-working solution and just add one line of code at a time until the problem surfaces, so as to pin-point the exact cause.
Thanks
EDIT:
I've been able to narrow down the source of the problem to one line of code:
public static bool GetFavWashPkgs(out List<WashPkg> wPkgs)
If I remove the "out" keyword, then compile, the designer crashing problem is resolved. Same applies to the "ref" keyword--also a no-no in this case. I have tried for an hour to re-create this anomaly in a more basic test, using a test class and test function, but to no avail. All I can report is that this "sensitive" function is overloaded, the custom class WashPkg has the attribute [serializable()], and the class in which this function resides is static. If I modify the function declaration so that the type of List is int instead of WashPkg, the problem is also resolved.
So at this point it's still a mystery as to why the designer doesn't like that function declaration.
I am using plugins for one of my Mac OS X(desktop) application. These plugins refer to a common file that contains base class implementation of both the plugins.
When the application refers to this common base class, the following message is displayed in the console by the system:
" is implemented in both and . One of the two will be used. Which one is undefined."
This console message is displayed from 10.5.x onwards.
However this does not cause any problem. But, I do not want my class name to be printed in the console. Can someone help to avoid this console message.
A possible way around is to #define the name of your class as something unrelated, so that it remains the same in your code, for your use, but is obfuscated in the executable.
I'd like a neater solution myself. I have searched quite a lot, and it seems that in general console messages are for solving problems, rather than for looking for them, and more specifically that this kind of message isn't really an issue.
One can also use an EXPORTED_SYMBOLS_FILE or an UNEXPORTED_SYMBOLS_FILE (these are the relevant build setting names) to state which symbols you do or don't want to export. Often, you want to export at least one, but it can reduce the number of names that are revealed.
We're trying to learn to use T4 Templates. I have a desire to use the System.Data.Entity.Design.PluralizationServices library in order to better pluralize some Entity Model names within my template, but I've come across some issues in the achievement of this goal.
Running code to generate output text. I think this is possible, but if it's not going to work, then there's no need to go any further. (I could call Date.Now.ToString() and get the expected result. I haven't tried anything much more complicated yet)
I am in a Silverlight App, and so I can't add a reference to the project for the PluralizationServices library in the place where I need the generated .cs file. I was planning on just moving the .tt file to a non-SL app, using the namespace and moving the generated file to the correct space. Haven't got that far yet, so I don't know how much trouble that will be, but it doesn't seem like it should be too hard.
My current problem is that when I import the namespace of the library, I get an "ErrorGeneratingOutput" and I haven't been able to move on past that yet.
I am having a hard time finding information about how the import command works, so I assume that it's just obvious. At the same time though, this one doesn't work so I wonder if it might be an exception to the standard.
<##import namespace="System.Data.Entity.Design.PluralizationServices" #>
I have no idea why adding this line (and only this line) causes everything to break. I haven't even started to try to use it yet! Is there something somewhere about libraries in T4 that I should know or read? Thanks!
Here a description of how the import directive works. Without knowing the actual error T4 reports when transofrming the template in your environment, I can only guess that you didn't add an assembly directive to reference the System.Data.Entity.Design assembly. If this doesn't work, look at the errors reported by T4 in the Error List of visual studio, which should be more helpful than "ErrorGeneratingOutput".