What a SID actually encodes

A Security Identifier is a structured value, not an opaque string: the revision number, the identifier authority, and a chain of sub-authorities together uniquely identify a security principal — a user, group, or computer — across a Windows domain or local machine. The final sub-authority (the RID, relative identifier) is what distinguishes accounts within the same domain; well-known low RIDs like 500 (built-in Administrator) and 512 (Domain Admins) are fixed by convention across every Windows installation, which is why this tool can recognize them by number while domain-specific SIDs — the long S-1-5-21-... form — can't be looked up generically, since the domain identifier portion is different in every environment.

Reading an ACE without memorizing the abbreviations

SDDL packs a lot into very little space by design — a full access control entry like `(A;;FA;;;SY)` means "Allow; no inheritance flags; File All Access; (object type/inherited-from blank); to SY (Local System)." That density is exactly why manually parsing an SDDL string by eye is error-prone and slow: it's easy to miscount fields or misread a two-letter code, especially in a long DACL with many entries. This tool exists to turn that dense string into a normal table — type, flags, rights, and trustee as separate readable columns — for exactly the cases where someone pastes a raw SDDL string from `icacls` or `Get-Acl` and needs to know, quickly, who actually has what access.