Exclude files or code from obfuscation

[hadiidbouk]

In this PR :

1 - Exclude files from obfuscation using -ignore-files (please not this will only obfuscate the class/struct.. name).
2 - Exclude properties/variables/classes.. that start with a tag using excluded-prefix-tag.
3 - Exclude properties/variables/classes.. that end with a tag using excluded-suffix-tag.
4 - Enable properties obfuscations.

[rockbruno]

Looks interesting! I have a few questions:

• What -ignore-files is doing is ignore registering a symbol if the name matches the name of an "ignored file", did you mean to ignore files completely? If so, is there a reason to do so? That would only compile correctly if your file doesn't reference anything from other files.
• Ignoring specific symbols is great, but prefixes and suffixes sounds like something super specific that people wouldn't normally do, what if we made a single -ignore-symbols instead?

[rockbruno]

Some new tests would also be great 🙂

[hadiidbouk]

• -ignore-files I agree with you. The goal was to make a public class with all the methods available to the user, this can be done easily if we have information about the access control (e.g Ignore obfuscation of all public access control). I searched a lot and there Is no way to use reflection and getting the access controls.

There is two solution came to my mind :

1. Add a JSON file that contains the class name and all the functions inside this class that shouldn't obfuscate. but in this way, we should know the variable/function parent. like a method bla() is inside the class Foo - because we cannot just ignore obfuscation of all the methods that named bla.
2. The second way, Is to add tags to all public apis/variables/classes.. that should be visible to the user and use the exclude-prefix(suffix)-tag to ignore these from being obfuscated. And when the obfuscation finishes we can clear the added tag from these APIs.

What do you recommend?

• Some libraries add a prefix to each class containing the company name or the pod name, and some tags can be as a suffix like the __s added in this library.

[rockbruno]

You can retrieve access control - I don't have it from the top of my head but if you use -print-sourcekit-queries you can see that SourceKit adds info if something is public. That will allow SDKs to ignore public stuff. Will take some tinkering but it's definitely feasible. I actually want to drop the whole tag thing because it's causes a lot of problems with someone random library accidentally name something like your tag.

[hadiidbouk]

Also why static properties are not obfuscated?

public static let xxxxxxxxxxxxxxxxxxxxxxxxxxxxx__npc7a: Double = 5

the xx..xx is my property name, but it's not obfuscated.

It seems a problem with static let because static var worked just fine

[rockbruno]

Can you run your code with -print-sourcekit-queries and see if there's any difference when your property is a let? It might use an identifier that is not mapped in SwiftShield.

[hadiidbouk]

{removed large output}

[hadiidbouk]

private final let is working.
The problem with static access control.

[rockbruno]

Sorry, it's actually -show-sourcekit-queries. They look like this:

          key.entities: [
            {
              key.kind: source.lang.swift.ref.class,
              key.name: "B",
              key.usr: "s:28index_is_test_candidate_objc1BC",
              key.line: 25,
              key.column: 31
            },]

[hadiidbouk]

{removed large output}

[rockbruno]

Can you move this output to a pastebin or something like that so this page doesn't get cluttered?
The problem is that your static properties are indexed as var.static, but in this line: https://github.com/rockbruno/swiftshield/pull/31/files#diff-ee2848e911891c82d85100c000e42012R30

you only check for var.instance and var.class :)

[hadiidbouk]

Thank you!

[hadiidbouk]

@rockbruno @vrujbr please check the edited files

[rockbruno]

Awesome! I haven't tested it yet but the shape of it looks exactly like we need 🙂 I'll just nitpick the structure of the code:

[rockbruno]

I do not understand what this is supposed to be doing, is it a leftover from something?

[hadiidbouk]

leftover, I will remove it.

[rockbruno]

Do not use force unwrap - If storing the protocols here are needed, we can pre-init it for safety reasons 🙂
var publicProtocols: Set<String> = []

[hadiidbouk]

Ok

[rockbruno]

To avoid making getNameData get super big, we can move this logic to a separate shouldIgnoreSymbol()-like method, makes sense?

[hadiidbouk]

Ok

[rockbruno]

Let's avoid comments unless explaining an intent is needed - what is happening should be clear enough through the name of the properties we're dealing with.

[rockbruno]

I would avoid dealing with strings directly. We can make an enum to handle visibility identifiers. I already did that for kinds, so we can follow the same pattern 🙂

[rockbruno]

Same thing here (not dealing with strings directly), SKAPI already has a method to return what an identifier is - I think we just need to add the protocol case.

[rockbruno]

If I understood this correctly, shouldn't this be simply publicProtocols.contains(usr) instead of a loop? This is running in O(nˆ2)

[hadiidbouk]

No, because the receiver_usr isn't returning just a name, It's something like that
s:17ObfuscationSource14ViewControllerC5countSivp

[rockbruno]

I see now. The problem is that using contains inside an usr will likely not work in a bigger app because nothing stops other modules from having private protocols with the same name as your public one. I think you need to store the protocol usrs in publicProtocols instead of their names to avoid this loop.

But I'm getting some bad vibes, is this deterministic? I'm having the impression that a public protocol's method would be wrongly obfuscated if the order of the files changed. If you look at isReferencingInternal(), I had to even make it recursive to make it work. Things are slightly more difficult here because it happens before everything, but I think it's gonna work nicely in the end.

[rockbruno]

We can remove these leftovers

[hadiidbouk]

I will remove it.

[rockbruno]

I think that's also a leftover right?

[hadiidbouk]

leftover, I will remove it.

[vrujbr]

Is this safe? Wouldn't it crash on none-array dict?

[rockbruno]

I took this weekend to run the property obfuscation feature (and to implement the public-ignoring myself to see if I could do it) to see if there no hidden problems in it, and I found a couple 😢

In regards to obfuscating properties, it turns out that it really messes up Codable. Because most people use it to parse JSONs from the web, changing the properties will break parsing. The fix for this is to explicitely define Codable's keys through CodingKeys, but unfortunately people don't do this due to Codable's auto-derivation properties. I think there are some SourceKit bugs as well because some properties weren't being indexed (It could be an error on my side though. Haven't checked it deeply)

Regarding avoiding publics, I tried to do it and faced many problems, including some we haven't noticed before, which is that extensions also share the protocol problems:

// Both are valid. bar() is public in both
extension Foo {
    public func bar() {}
}

public extension Foo {
    func bar()
}

SourceKit isn't very helpful here since it does not mark bar() as public in the latter one, although you could find this out since it's inside a public extension. There's nothing in the tool that does this kind of backwards check though, and I think blindly checking for publics in previous scopes would return you some false positives (internal method in public class isn't public).

I would deeply investigate all these edge cases before trying to develop this again, but I still believe it's possible. I unfortunately do not know what to do in regards to properties though.

[vrujbr]

Great work @rockbruno! To these edge cases..
I say don't worry about the extensions. Mention in readme that public methods in public extensions have to be specifically marked public in order for them not be obfuscated with omit public argument.
With the properties it's a bit worse. I guess you could do the same and force people to use coding keys. Or omit Codable all together?

[iOSleep]

if you enable property, confirm no storyboard property in use

[hadiidbouk]

Any update on this? Is there any plan for the future for ignoring public methods?

[rockbruno]

My previous comment still holds true, SourceKit doesn't cover all ways to make something public and things that are derived need to be ignored, so I don't have a good outlook for this 😢

[rockbruno]

The tool has been remade. SDK mode exists, and although the bugs weren't fixed, we detailed them in the section. The exclusion part can still be done.