Problem
The Settings tab protection management UX is confusing and hard to use. The GUI directly exposes the raw .crproj rule model without any abstraction, making common tasks unnecessarily difficult.
Current flow (too many steps)
- Go to Settings tab → select module in left list
- Click [+] to add a rule → a blank pattern
"true" appears
- Double-click the rule to open the Edit Rule dialog
- In the dialog: set pattern, pick preset, toggle inherit, then manually add protections with [+]
- Each protection shows
[Action: Add/Remove] + [Protection dropdown]
- Click "Done"
Specific pain points
| Problem |
Impact |
Rules list shows only the pattern (e.g. "true") |
User can't see which protections are active without opening each rule |
| Presets are invisible |
"Normal" preset auto-adds protections but they're not listed anywhere visible |
| No "effective protections" view |
Rules stack with inheritance — user must mentally compute the final result |
| Add/Remove action is confusing |
Most users want a checkbox, not a layered override. "Remove" only makes sense for overriding presets |
| Pattern system has no help |
is-type and has-attr('DataContractAttribute') is powerful but no examples or autocomplete |
| No protection descriptions in the list |
After adding a protection, you just see the ID, not what it does |
Why Add/Remove exists (context for implementer)
The rule system is a layered override chain — evaluated per-target:
For each type/method:
1. Start empty
2. For each matching rule:
- Inherit=false → clear all
- Apply preset → auto-add protections at/below that level
- Action=Add → add to set
- Action=Remove → remove from set
3. Result = effective protections for this target
Remove exists so you can say "use Normal preset but exclude renaming for serialized classes." This is the right design for .crproj files but the wrong abstraction for a GUI.
Proposed UX improvement
Simple mode (default)
Replace the rules list with a protection checklist:
Protections [Preset: ▾ Normal]
─────────────────────────────────────────────────────
☑ Anti Debug Prevents debugger attachment
☑ Anti Dump Prevents memory dumping
☑ Anti IL DASM Disables IL disassemblers
☐ Anti Tamper Method body encryption (slower startup)
☑ Constants Encrypts constants and strings
☑ Control Flow Obfuscates control flow
☐ Invalid Meta Adds invalid metadata entries
☑ Ref Proxy Hides method references behind proxies
☑ Rename Renames symbols (supports WPF/BAML)
☑ Resources Encrypts embedded resources
─────────────────────────────────────────────────────
[Clear All] [Select All] [Advanced Rules ▸]
- Preset dropdown toggles groups of checkboxes
- Checking/unchecking directly modifies the protection set
- Applies to selected module (or global)
- Each row shows name + one-line description
- Click a protection row to expand per-protection settings (e.g. rename mode)
Advanced mode (for power users)
The current rule editor, but improved:
- Show effective protections inline in the rules list (not just the pattern)
- Pattern builder with examples/autocomplete
- Preview which types/methods a pattern matches
Implementation notes
- The underlying
Rule / SettingItem<Protection> model doesn't need to change
- Simple mode generates the equivalent rules behind the scenes
- A single rule with
pattern="true" + individual Add items = the simple checklist
- "Advanced Rules" button reveals the current rule editor for overrides
Related code
ConfuserEx/Views/SettingsTabView.xaml — Settings tab layout
ConfuserEx/Views/ProjectRuleView.xaml — Rule edit dialog
ConfuserEx/ViewModel/UI/SettingsTabVM.cs — Settings tab logic
ConfuserEx/ViewModel/Project/ProjectRuleVM.cs — Rule ViewModel
ConfuserEx/ViewModel/Project/ProjectSettingVM.cs — Protection setting ViewModel
Confuser.Core/Marker.cs:242 — ApplyRules() — rule resolution logic
Confuser.Core/Project/ConfuserProject.cs:261 — SettingItemAction enum
Confuser.Core/ProtectionPreset.cs — Preset levels
Problem
The Settings tab protection management UX is confusing and hard to use. The GUI directly exposes the raw
.crprojrule model without any abstraction, making common tasks unnecessarily difficult.Current flow (too many steps)
"true"appears[Action: Add/Remove]+[Protection dropdown]Specific pain points
"true")is-type and has-attr('DataContractAttribute')is powerful but no examples or autocompleteWhy Add/Remove exists (context for implementer)
The rule system is a layered override chain — evaluated per-target:
Removeexists so you can say "use Normal preset but exclude renaming for serialized classes." This is the right design for.crprojfiles but the wrong abstraction for a GUI.Proposed UX improvement
Simple mode (default)
Replace the rules list with a protection checklist:
Advanced mode (for power users)
The current rule editor, but improved:
Implementation notes
Rule/SettingItem<Protection>model doesn't need to changepattern="true"+ individualAdditems = the simple checklistRelated code
ConfuserEx/Views/SettingsTabView.xaml— Settings tab layoutConfuserEx/Views/ProjectRuleView.xaml— Rule edit dialogConfuserEx/ViewModel/UI/SettingsTabVM.cs— Settings tab logicConfuserEx/ViewModel/Project/ProjectRuleVM.cs— Rule ViewModelConfuserEx/ViewModel/Project/ProjectSettingVM.cs— Protection setting ViewModelConfuser.Core/Marker.cs:242—ApplyRules()— rule resolution logicConfuser.Core/Project/ConfuserProject.cs:261—SettingItemActionenumConfuser.Core/ProtectionPreset.cs— Preset levels