Cline rules

1# YARA-Style-Guide
2A specification and style guide for YARA rules
3 
4## Introduction 
5 
6YARA is a powerful and versatile tool for malware detection, used by security researchers and analysts all over the world. YARA rules are at the heart of this tool, providing a structured way to identify and classify malware based on various characteristics such as file names, sizes, and contents.
7 
8Creating effective YARA rules is not an easy task, and it requires a deep understanding of the malware landscape, as well as knowledge of YARA's syntax and capabilities. To help security professionals create high-quality and efficient YARA rules, we have created this style guide.
9 
10This guide will cover the best practices for YARA rule structure and contents, including recommendations for naming conventions, syntax, and content selection. By following these guidelines, you will be able to create YARA rules that are accurate, concise, and easy to read and maintain.
11 
12Whether you are a seasoned security professional or just getting started with YARA, this guide will provide you with the tools you need to create effective malware detection rules.
13 
14## Scope
15 
16This YARA Style Guide is primarily focused on enhancing readability, maintainability, and usability of YARA rules. It doesn’t delve into the aspects of performance or resource utilization, although adhering to these best practices can inadvertently lead to optimized rule set performance. (e.g., the order of the expressions in the condition)
17 
18For in-depth insights and strategies on performance and resource optimization, we recommend exploring [this project](https://github.com/Neo23x0/YARA-Performance-Guidelines/).
19 
20## Rule Names
21 
22```yara
23rule TBD
24```
25 
26## Rule Name
27 
28The rule name is sometimes the only or first piece of information that is shown to a user. Therefore it should already include information about the type of threat, tags that classify the threat, a descriptive identifier and even an information about the context or a period in which the rule was created. 
29 
30The different values are separated by an underscore character (`_`). 
31 
32The values are ordered from generic to specific.
33 
34The most generic values are the category of the threat. The following list contains the most common generic classifiers.
35 
36### Main Categories
37 
38- **MAL** (malware) : used for malware
39- **HKTL** (hacktool) : used for hack tools
40- **WEBSHELL** : used for web shells
41- **EXPL** (exploit) : used for exploit codes (e.g., proof-of-concept code, exploit payloads etc.)
42- **VULN** (vulnerability) : used for vulnerabilities (e.g., a vulnerable driver, a vulnerable JAVA library etc.)
43- **SUSP** (suspicious) : used for all kinds of anomalies, suspicious capabilities (e.g., obfuscated code, shell codes, suspicious combination of imports, suspicious set of commands in a script etc.)
44- **PUA** : used for possibly unwanted applications
45 
46Other categories that proofed to be useful when classifying YARA rules:
47 
48Important: the lists are not exhaustive and can be extended at any time if necessary. 
49 
50### Intention / Background
51 
52- **APT** (advanced persistent threat): used to indicate that the 
53- **CRIME** (crime group activity): 
54- **ANOMALY** (generic and suspicious characteristics)
55- **RANSOM**
56 
57### Types of Malware / File
58 
59- **RAT**
60- **Implant**
61- **Stealer**
62- **Loader**
63- **Crypter**
64- **PEEXE** (often omitted)
65- **DRV** : used for drivers
66 
67### Operating System
68 
69- **WIN** (often omitted)
70- **LNX**
71- **MacOS**
72 
73### Architecture
74 
75- **X64** (often omitted)
76- **X86** (often omitted)
77- **ARM**
78- **SPARC**
79 
80### Technology
81 
82- **PE** (often omitted) / - **ELF**
83- **PS** / **PS1** / **VBS** / **BAT** / **JS**
84- **NET** / **GO** / **Rust**
85- **PHP** / **JSP** / **ASP**
86- **MalDoc**
87- **LNK**
88- **ZIP**
89- **RAR**
90 
91### Modifiers
92 
93- **OBFUSC** : used for obfuscated samples 
94- **Encoded** : used for encoded versions of payloads
95- **Unpacked** : used for unpacked payloads
96- **InMemory** : used for code that can only be found when loaded into memory
97 
98### Packers / Installers
99 
100- **SFX** : used for self-extracting archives
101- **UPX**
102- **Themida**
103- **NSIS**
104 
105### Threat Actor Identifiers
106 
107The threat actor identifier tags are straight forward. 
108 
109The list only contains examples:
110 
111- **APT28**
112- **UNC4736**
113- **Lazarus**
114 
115### Threat Identifiers
116 
117The threat identifier tags are straight forward. 
118 
119- **CobaltStrike**
120- **PlugX**
121- **QakBot**
122 
123### Other Often Used Keywords
124 
125- **TINY** : used for very small files
126- **HUGE** : used for very big files
127- **UAC_Bypass**
128- **Base64**
129 
130### Suffixes to Guarantee Uniqueness
131 
132The suffixes lower the chances that two analysts choose the same rule name by adding values to the rule.
133 
134The recommended values are:
135 
136- **MonthYear** : e.g., `May23`, `Jan19`
137- **Number** : e.g., `*_1`, `*_2`
138 
139### Combining the Categories
140 
141The mentioned keywords are combined to create a more specific classification.
142 
143Here are some examples:
144 
145- `SUSP_APT_*`: used for forensic artifacts found on systems compromised by a threat actor (e.g., hack tool outputs, command line flag combinations, redirected standard outputs, log file contents etc.)
146- `MAL_CRIME_RANSOM_LNX_Rust_*` : used for malware used by ransomware crime groups written in Rust for the Linux platform
147- `WEBSHELL_APT_ASP_*` : used for ASP webshell used by nation state threat actors 
148 
149### Full Rule Name Examples
150 
151- `APT_MAL_CozyBear_ELF_Loader_Apr18` : Rule written in April 2018 for a loader used by the threat actor Cozy Bear written for the Linux platform. 
152- `SUSP_Anomaly_LNK_Huge_Apr22` : Rule written in April 2022 for suspiciously big link files
153- `MAL_CRIME_RANSOM_PS1_OBFUSC_Loader_May23` : Rule written in May 2023xw for an obfuscated PowerShell loader noticed in a Ransomware campaign
154 
155 
156## Rule Structure and Values
157 
158```yara
159rule RULE_NAME : TAGS {
160    meta:
161        description = "Detects ..."
162        author = "Author Name / Company / Org"
163        date = "YYYY-MM-DD"
164        reference = "URL / Internal Research"
165        [OPTIONAL META DATA FIELDS]
166    strings:
167        $string1 = "value"
168    condition:
169        header_check
170        file_size_limitation
171        other_limitations
172        string_combinations
173        false_positive_filters
174}
175```
176 
177 
178## Indentation
179 
180Utilize indentation to enhance the readability of your YARA rules. It's common practice to use either 3 or 4 spaces or tabs for indentation in most published rules. This consistency aids in maintaining a clean and organized presentation of the code, making it easier to read and understand.
181 
182DON'T
183```yara
184rule MY_RULE {
185meta:
186description = "my test rule"
187author = "John Galt"
188strings:
189$s1 = "eval("
190$s2 = "WScript.Shell"
191condition:
192filesize < 10KB and all of them 
193}
194 
195rule MY_RULE {
196 meta:
197  description = "my test rule"
198  author = "John Galt"
199 strings:
200  $s1 = "eval("
201  $s2 = "WScript.Shell"
202 condition:
203  filesize < 10KB and all of them 
204}
205```
206 
207DO
208```yara
209rule MY_RULE {
210   meta:
211      description = "my test rule"
212      author = "John Galt"
213   strings:
214      $s1 = "eval("
215      $s2 = "WScript.Shell"
216   condition:
217      filesize < 10KB and all of them 
218}
219```
220 
221### Rule Tags
222 
223While rule tags can be employed to classify and group related rules together, in this guide, we advise incorporating main categories directly into the rule name for more straightforward identification. Additional tags that are less directly related to the main category should be included in a dedicated meta data field called "tags". This approach keeps rule names concise while also offering the flexibility to include more context-specific tags.
224 
225The chapter on the rule names explains how to include main categories in the rule name:
226 
227```yara
228rule RULE_NAME_MAIN_CATEGORY1_MAIN_CATEGORY2 {
229    ...
230}
231```
232 
233For additional, less directly related tags, you can add them to the tags field in the meta data section:
234 
235```yara
236rule RULE_NAME {
237    meta:
238        tags = "TAG1, TAG2, TAG3"
239    ...
240}
241```
242 
243These tags can denote a variety of attributes such as threat actor names (e.g., APT28, Lazarus), malware families (e.g., Emotet, TrickBot), or types of attacks (e.g., phishing, ransomware). See the chapter on rule names for details.
244 
245## Rule Meta Data
246 
247The meta section provides additional information about the rule. This can include the author's name, a reference to the research paper or blog post that describes the malware, the date when the rule was written, or any other information that you consider relevant.
248 
249```yara
250rule RULE_NAME : TAGS {
251    meta:
252        description = "Detects ..."
253        author = "Author Name / Company / Org"
254        date = "YYYY-MM-DD"
255        reference = "URL / Internal Research"
256        score = [0-100]
257        [OPTIONAL META DATA FIELDS]
258    ...
259}
260```
261 
262As the name suggests, the optional meta fields are not required for the rule to function, but they can provide valuable context to anyone who uses the rule.
263 
264### Mandatory Meta Data Fields
265 
266Certain meta data fields are indispensable as they contain critical information for analysts who work with the rule or evaluate rule matches.
267 
268- `description`: This should provide a clear and succinct description of what the rule is designed to detect.
269- `author`: This field specifies the author, group, or organization that composed or released the rule.
270- `reference`: This should link to a report, source code repository, website, private report name, identifier, or a short description of the source from which the rule was derived.
271- `date`: This denotes the creation date of the rule and should be in the format YYYY-MM-DD.
272 
273The following chapters describe the values in more detail. 
274 
275#### Description
276 
277| Field  | Description                                  |
278|--------|----------------------------------------------|
279| Value | String |
280| Preferred Length | 60-400 characters |
281| Avoid | URLs |
282| Prefer | Value starts with "Detects ..." |
283 
284The "Description" field plays a crucial role in conveying the core intent and scope of a YARA rule. Here's a guide to constructing an effective description:
285 
286Preferred Length: It's recommended to keep the description between 60 to 400 characters. This range ensures the description is concise, yet provides enough information for analysts and other users to understand the rule's purpose without overwhelming them.
287 
288Avoid URLs: Refrain from including URLs directly in the description. If a reference is necessary, it's better to use the reference meta field or another dedicated field for URLs.
289 
290Starting Convention: Start your description with the phrase "Detects ...". This format offers clarity, ensuring users can quickly ascertain what the YARA rule identifies or monitors.
291 
292#### Author
293 
294| Field  | Description                                  |
295|--------|----------------------------------------------|
296| Value | String |
297| Avoid | URLs |
298| Prefer | Full name, Twitter handles |
299 
300The "Author" field provides attribution and aids in understanding the provenance of a YARA rule. Here's how to best structure this field:
301 
302Preferred Length: There's no strict length guideline for the "Author" field. However, clarity and brevity are always appreciated.
303 
304Avoid URLs: Direct URLs shouldn't be placed in the "Author" field. If you need to provide additional information about the author or the source, consider using other meta fields or providing accompanying documentation.
305 
306Author Identification: It's best to use the full name of the author for clear attribution. If you want to give credit using a social media identifier, Twitter handles are preferable.
307 
308Multiple Authors: If a rule is a result of collaborative work, instead of using the "Author" field multiple times, consolidate the authors into a single field using a comma-separated list. This ensures the meta section remains tidy and concise.
309 
310#### Reference
311 
312| Field  | Description                                  |
313|--------|----------------------------------------------|
314| Value | List of Strings |
315| Avoid | Unstable links, links to private resources |
316| Prefer | URLs |
317 
318The "Reference" field is crucial for providing context and background information regarding the YARA rule. Here's a guide to populating this field optimally:
319 
320What Can a Reference Be? A reference can be a direct link to a report from which the YARA rule was derived, copied, or where the specific rule can be found. This provides clarity on the rule's origins and its foundational evidence.
321 
322Preferred Length: While there isn't a hard limit on the length for the "Reference" field, it's essential that any references provided are concise and directly relevant.
323 
324Avoid Unstable Links and Private Resources: It's best not to include URLs that might become inactive in the near future, rendering the reference useless. Additionally, links that lead to private, restricted, or paywalled resources should be avoided, as they may not be accessible to all users.
325 
326Preference for URLs: When providing references, it's optimal to use direct URLs that lead to public and stable sources of information, such as research papers, blog posts, or official advisories.
327 
328Internal Work: If the YARA rule is derived from your own research, ideas, or observations rather than from external publications, it's appropriate to use "Internal Research" as the value for the reference. This indicates that the rule's origin is proprietary and not directly linked to an external public source.
329 
330#### Date
331 
332| Field  | Description                                  |
333|--------|----------------------------------------------|
334| Value | String |
335| Preferred Format | YYYY-MM-DD |
336 
337The "Date" field serves as a crucial indicator of when a YARA rule was initially formulated. This timestamp is essential to understand the context and timing of the rule's creation. Here's how you can optimally populate this field:
338 
339Format Requirement: When inputting the date for your rule, ensure that you use the format "YYYY-MM-DD". This standardized format ensures consistency across all rules and ease of understanding for analysts and researchers.
340 
341Reflecting the Creation Date: It's essential to note that the "Date" field should exclusively indicate when the rule was originally created. It is not meant to showcase when the rule was published or any subsequent modifications made to it.
342 
343Modifications: If you make any changes to a YARA rule after its original creation, you should indicate this in a separate field named "modified". This distinction ensures clarity about the rule's original inception and any updates that may have been made subsequently.
344 
345### Optional Meta Data Fields
346 
347While mandatory meta data fields provide essential information about a YARA rule, optional fields offer supplementary details that can further enhance the context, functionality, and traceability of the rule. They're particularly useful for providing additional search parameters, recording changes, and maintaining rule versioning.
348 
349- `hash`: This field can hold one or more MD5, SHA1, SHA256 values. You can use the hash field multiple times if needed. It can be a list of hash values. The SHA256 hash is the preferred value. 
350- `score`: A numerical score between 0 and 100, which is used to represent a combination of the rule's severity (how critical the threat it identifies is) and specificity (how uniquely the rule identifies a particular threat). The score can aid in prioritizing responses to rule matches, e.g. rules with higher score are more critical. 
351- `modified`: This specifies the last modification date of the rule, which is useful when the rule gets updated post its initial creation. The date should be in the YYYY-MM-DD format.
352- `old_rule_name`: This is used to hold the previous name of the rule. It allows for searches using the old name in case the name has been changed.
353tags: This is used to include a list of tags. Each tag should be separated by a comma.
354- `license`: A license under which the rule has been released.
355 
356#### Hash 
357 
358| Field  | Description                                  |
359|--------|----------------------------------------------|
360| Value | List of Strings |
361| Avoid | N/A |
362| Prefer | SHA256 hash |
363 
364The "Hash" field in a YARA rule is integral to the detection process, as it provides a distinct identifier for the file to be matched. Properly populating this field ensures optimal rule execution and precise matching. Here are some guidelines to consider:
365 
366Hash Type: While you might encounter various hash types, it's preferable to use the SHA256 hash. It offers a higher level of specificity and reduces the likelihood of collisions compared to some other hash types.
367 
368Direct File Reference: The hash should directly correlate to the file that the YARA rule is intended to match. This ensures that the rule effectively detects the intended threat without false positives.
369 
370Avoid Archive Hashes: It's essential to avoid using hashes of archives where the sample might have been found. Instead, focus on the extracted file or the malicious content itself. By doing so, you ensure that the detection is specific to the threat and not the container it might have come in.
371 
372Exception for Memory-based Matches: An exception to the above is when your rule is designed to detect samples loaded into memory. In scenarios where the rule might not detect a sample on disk but identifies the unpacked, unencrypted, or loaded sample in memory, the hash related to that memory form should be used.
373 
374#### Score 
375 
376| Field  | Description                                  |
377|--------|----------------------------------------------|
378| Value | Number|
379| Range | 0-100 |
380 
381The "Score" field in a YARA rule plays a pivotal role in gauging the potential impact and uniqueness of a detected threat. This field incorporates two key dimensions: the severity of the detected threat and the specificity of the rule in identifying it. Here's a breakdown of what you should know:
382 
383Value Range: The score is a numerical value ranging between 0 and 100. It's not just an arbitrary number; it offers an insight into the potential risks associated with a rule match.
384 
385Severity and Specificity: This score embodies two essential characteristics:
386 
387Severity: It indicates how critical or detrimental the detected threat is. A high severity score points to potentially significant damage or impact if the threat is not addressed.
388Specificity: It tells you how uniquely the rule identifies a particular threat, ensuring that it's not just catching benign or unrelated items.
389Response Prioritization: One of the most significant utilities of the score is in threat response prioritization. When inundated with numerous rule matches, security analysts can prioritize responses based on the score. A higher score typically suggests that the rule match is more critical and should be addressed with higher urgency.
390 
391Incorporating a well-thought-out score in your YARA rules ensures a more strategic and effective approach to threat detection and response.
392 
393Use this table as a guideline to assign a score, ensuring that your rule appropriately represents the threat level:
394 
395| Score Range | Significance Level                         | Examples & Use Cases                                                           |
396|-------------|--------------------------------------------|--------------------------------------------------------------------------------|
397| 0-39        | Very Low Significance                      | Capabilities, packers etc. (often combined for a higher total score)            |
398| 40-59       | Noteworthy                                 | Uncommon packers or those often used by malware, PE header anomalies            |
399| 60-79       | Suspicious                                 | Heuristics matches, obfuscation rules, generic detection rules                  |
400| 80-100      | High (Direct matches on malware/hack tools)| Malware, hack tools, and other malicious entities identified with high accuracy |
401 
402## Rule Strings
403 
404The strings section of a YARA rule specifies the sequences of bytes, strings, or regular expressions that will be searched for within the file. Each string is given a unique identifier that can be used in the condition section to refer to the string.
405 
406```yara
407rule RULE_NAME {
408    ...
409    strings:
410        $s1 = "value"
411        $s2 = { E2 34 F1 67 }
412        $r1 = /abc[def]+/
413    ...
414}
415```
416 
417In the example above, `$s1` is a simple string, `$s2` is a sequence of bytes, and `$r1` is a regular expression.
418 
419### String Identifiers
420 
421There are some best practices in regards to the use of string values in YARA.
422 
423Opt for Readable String Values
424For enhanced readability, avoid using hexadecimal representation for string values that can be effectively represented with standard strings. Exceptions to this rule include strings containing control characters like \t (tab) or \n (newline), where the hexadecimal format is preferred.
425 
426Avoid:
427 
428```yara
429$s1 = { 46 72 6F 6D 42 61 73 65 36 34 53 74 72 69 6E 67 28 }
430```
431 
432Recommended:
433 
434```yara
435$s1 = "FromBase64String("
436```
437 
438#### Choose Efficient String Identifiers
439 
440Opt for concise or descriptive identifiers for strings to enhance the readability of your YARA rules. Avoid long, non-descriptive identifiers, as they can clutter the code and make conditions, especially complex ones, difficult to read and understand.
441 
442Avoid:
443 
444```yara
445   $string_value_footer_1 = "eval("
446   $selection_14 = "eval("
447...
448condition:
449   all of (selection_*) and 3 of ($string_value_footer)
450```
451Recommended:
452 
453```yara
454   $s1 = "eval("
455   $eval = "eval("
456condition:
457   all of (s*) and $eval
458```
459 
460Incorporating these practices ensures your YARA rules are not only functional but also user-friendly, fostering an environment of efficiency and collaboration among security professionals.
461 
462### Hex Identifiers
463 
464For hexadecimal representations that primarily consist of ASCII characters, it’s helpful to include the ASCII string representation or the readable portions thereof in a comment, enhancing understandability.
465 
466```yara
467   /* )));\nIEX( */
468   $s1 = { 29 29 29 3b 0a 49 45 58 28 0a }
469```
470 
471To enhance readability, it's advisable to segment hex identifiers at every 16-byte interval. This practice is particularly beneficial for lengthy values, allowing observers to quickly gauge the length of the value without the need to horizontally scroll through the code.
472 
473```yara
474   $s1 = { 2c 20 2a 79 6f 77 2e 69 20 26 20 30 78 46 46 29 
475           3b 0a 20 20 70 72 69 6e 74 66 20 28 28 28 2a 79 
476           6f 77 2e 69 20 26 20 30 78 66 66 29 20 3d 3d 20 
477           30 78 34 31 29 20 3f 20 22 4c 49 54 54 4c 45 5c 
478           6e 22 20 3a 20 22 42 49 47 5c 6e 22 29 3b 0a 20 
479           20 70 72 69 6e 74 66 20 28 22 73 68 6f 72 74 20 
480           25 64 3b 20 20 69 6e 74 }
481```
482 
483### Regular Expressions
484 
485TBD
486 
487### Categorizing Strings: The Triad Approach ($x*, $s*, $a*)
488 
489Understanding the categorization of strings is crucial in enhancing the efficiency and accuracy of YARA rules. We propose a three-category approach to organize and identify strings effectively:
490 
4911. **Highly Specific Strings ($x*)**
492   - These are unique identifiers, characterized by their specificity to a particular threat. Their occurrence is almost exclusively associated with the intended target, making them highly reliable indicators.
493   - **Notation:** We designate these strings with an `x` prefix.
494 
4952. **Grouped Strings ($s*)**
496   - These strings may not be distinctive individually but become significant when considered as part of a collective group. These sets of strings, though not unique on their own, can be indicative of a threat when found together.
497   - **Notation:** They are marked with an `s` prefix to indicate their collective utility.
498 
4993. **Pre-Selection Strings ($a*)**
500   - These are commonly found strings that don’t directly indicate a threat but are instrumental in narrowing down the file type or format under scrutiny. They play a pivotal role in optimizing the rule's performance by limiting the scope of the search.
501   - **Notation:** An `a` prefix is used to identify these auxiliary strings.
502 
503Example:
504 
505```yara
506rule HKTL_Go_EasyHack_Oct23 {
507   meta:
508      description = "Detects a Go based hack tool"
509      author = "John Galt"
510      date = "2023-09-13"
511      reference = "https://githoop.com/EdgyHackerFreak/EasyHack"
512   strings:
513      $a1 = "Go build"
514 
515      $x1 = "Usage: easyhack.exe -t [IP] -p [PORT]"
516      $x2 = "c0d3d by @EdgyHackerFreak"
517 
518      $s1 = "main.inject"
519      $s2 = "main.loadPayload"
520   condition:
521      uint16(0) == 0x5a4d
522      and filesize < 20MB
523      and $a1 
524      and (
525        1 of ($x*)
526        or all of ($s*)
527      )
528      or 4 of them
529}
530```
531 
532### False Positive Filters ($f*)
533 
534False positives can hinder the effectiveness of YARA rules. To address this, we introduce a method to manage potential false positives.
535 
536- Strings that might indicate benign or non-malicious patterns should be prefixed with `fp`
537- If a rule matches malicious patterns but also matches a `$fp*` string, the rule doesn't trigger
538 
539```yara
540rule HKTL_Go_EasyHack_Oct23 {
541   meta:
542      description = "Detects a Go based hack tool"
543      author = "John Galt"
544   strings:
545      $a1 = "Go build"
546 
547      $s1 = "main.inject"
548      $s2 = "main.loadPayload"
549 
550      $fp1 = "Copyright by CrappySoft" wide
551   condition:
552      uint16(0) == 0x5a4d
553      and filesize < 20MB
554      and $a1 
555      and all of ($s*)
556      and not 1 of ($fp*)
557}
558```
559 
560## Rule Condition
561 
562The condition section of a YARA rule specifies the conditions that must be met for the rule to be considered a match. This is where the magic of YARA really happens. Conditions can be simple or complex, combining multiple strings, byte sequences, and metadata checks.
563 
564```yara
565rule RULE_NAME : TAGS {
566    ...
567    condition:
568        header_check
569        file_size_limitation
570        other_limitations
571        string_combinations
572        false_positive_filters
573}
574```
575 
576In the example above, the condition would be met if the checks in header_check, file_size_limitation, other_limitations, string_combinations and false_positive_filters are true. It's important to write conditions in a way that optimizes performance, especially when dealing with large data sets or live traffic.
577 
578Remember, the conditions should reflect the detection logic of your rule, be it based on the presence of certain strings, file size restrictions, or other characteristics that define your target threat. Be cautious while defining conditions, as too broad or too lenient conditions might lead to a high number of false positives.
579 
580### Examples
581 
582```yara
583rule RULE_NAME : TAGS {
584    ...
585    condition:
586        uint16(0) == 0x5a4d 
587        and filesize < 300KB 
588        and pe.number_of_signature == 0
589        and all of ($s*)
590        and not 1 of ($fp*)
591}
592```
593 
594For improved clarity, it's advised to place a new line before the and keyword. Experience has demonstrated that this approach enhances readability, making rules quicker to understand.
595 
596When parts of the condition need to be combined using an or operator, it's recommended to encapsulate these components within an indented block:
597 
598```yara
599rule RULE_NAME : TAGS {
600    ...
601    condition:
602        uint16(0) == 0x5a4d 
603        and filesize < 300KB 
604        and pe.number_of_signature == 0
605        and (
606            1 of ($x*)
607            or 3 of them
608        )
609        and not 1 of ($fp*)
610}
611```
612 
613```yara
614rule RULE_NAME : TAGS {
615    ...
616    condition:
617        uint16(0) == 0x5a4d 
618        and filesize < 300KB 
619        and (
620            1 of ($x*)
621            or (
622                2 of ($s*) 
623                and 3 of them
624            )
625        )
626}
627```
628 
629For conditions that require the evaluation of multiple potential values, such as different file markers, the same indented block format should be applied:
630 
631```yara
632rule RULE_NAME : TAGS {
633    ...
634    condition:
635        (
636            uint16(0) == 0x5a4d     // MZ marker
637            or uint16(0) == 0x457f  // ELF marker
638        )
639        and filesize < 300KB 
640        and pe.number_of_signature == 0
641        and all of ($s*)
642        and not 1 of ($fp*)
643}
644```
645 
646Adhering to this format fosters easy readability and promotes a clean, structured presentation of the rule conditions.
647 
648## Tweaks
649 
650### String Matching FTW
651 
652It’s not uncommon for some to leverage looping and hashing techniques to identify patterns within the PE headers of files, as illustrated below. In this example, the author iteratively calculates the MD5 hash of the initial 256 bytes of code across all PE sections and contrasts it with a predetermined hash value.
653 
654```yara
655   condition:
656      for any var_sect in pe.sections:
657         (hash.md5( var_sect.raw_data_offset, 0x100 ) == "d99eb1e503cac3a1e90450d0c07e3ffc" )
658```
659 
660However, this approach is less efficient than it might initially appear. YARA is intrinsically designed for direct string and pattern matching, making it highly efficient in these tasks. Conversely, cycling through each section and calculating hashes can be resource-intensive and less optimal.
661 
662A more streamlined and efficient approach is to directly incorporate the 256 bytes as a hexadecimal string within the YARA rule. This modification bypasses the computational overhead of hashing and leverages YARA's innate efficiency in string matching, ensuring rapid and precise detection without unnecessary CPU consumption.
663