.RF     Random Fill

Syntax:

          .RF  expression1, [expression2]

See also:

.AS   .AT   .AZ   .DA   .DB   .DL   .DR   .DW   .HS   .TS  

Function:

The .RF directive can fill a portion of memory with randomly generated bytes. This can be useful for software security.

Boundary Sync:

In Version 3 of the SB-Assembler this directive will not perform a boundary sync.

Explanation:

The expression1 indicates the number of bytes that should be filled with randomly generated values. Expression1 may not contain any forward referenced labels. Expression1 may not be a negative number.

The optional expression2 can be used as a seed value for the pseudo random number generator. If expression2 is not used the pseudo random bytes generated are different every time the source file is assembled. By specifying the seed you can generate the same pseudo random sequence time after time. In Version 2 of the SB-Assemble the seed value is truncated to the lower 16 bits. In Version 3 the entire 32 bit value is used as seed value.

In Version 2 of the SB-Assembler the pseudo random sequence will repeat itself after 65536 generated bytes. This is not a big problem for I can't think of an application that would require more random bytes than that.
In Version 3 of the SB-Assembler the pseudo random sequence will repeat itself after 6,953,607,871,644 bytes, thanks to Python's better pseudo random number generator.

Be aware that even seeded random number sequences may differ on different platforms. Windows for instance generates totally different sequences than Linux Mint.

Because of the totally different pseudo random number generators of Version 2 and 3 of the SB-Assembler, they will not generate the same pseudo random number sequences when both are seeded with the same seed.

Examples:

For example the single chip processor 8051 (or its relatives) provide a few security levels to prevent software piracy. One of these levels of security encrypt the ROM contents when read by a programmer. Without the correct encryption key sequence this information is useless.
The encryption system of the 8051 uses a 32 byte encryption key. All bytes read are EXNORred with one of those key bytes. The keys are used in sequence over and over again. Now imagine that only 3 kB of the 4 kB program space is used in your 8051 system. That would leave an empty space of 1 kB in your ROM. If you don't put something in there all bytes from that empty space will read $FF. Using the encryption system will EXNOR all these $FF bytes with the encryption key sequence, resulting in exactly the encryption key sequence repeating over and over again every 32 bytes!
All a potential software pirate has to do is check to see if a 32 byte sequence repeats itself at the end of the program space to find out what your encryption key sequence is. Knowing the encryption key sequence he is now capable of decoding your entire program.
Filling the unused portion of your ROM with randomly generated bytes can easily fill this security hole. I don't say that it will become impossible to break your code if you do, but you will make it a lot harder for the software pirate to steal your life's work.

Examples:

         .RF  $1000-$     Fill up to 4kb with random numbers