1=head1 NAME 2 3perlfilter - Source Filters 4 5=head1 DESCRIPTION 6 7This article is about a little-known feature of Perl called 8I<source filters>. Source filters alter the program text of a module 9before Perl sees it, much as a C preprocessor alters the source text of 10a C program before the compiler sees it. This article tells you more 11about what source filters are, how they work, and how to write your 12own. 13 14The original purpose of source filters was to let you encrypt your 15program source to prevent casual piracy. This isn't all they can do, as 16you'll soon learn. But first, the basics. 17 18=head1 CONCEPTS 19 20Before the Perl interpreter can execute a Perl script, it must first 21read it from a file into memory for parsing and compilation. If that 22script itself includes other scripts with a C<use> or C<require> 23statement, then each of those scripts will have to be read from their 24respective files as well. 25 26Now think of each logical connection between the Perl parser and an 27individual file as a I<source stream>. A source stream is created when 28the Perl parser opens a file, it continues to exist as the source code 29is read into memory, and it is destroyed when Perl is finished parsing 30the file. If the parser encounters a C<require> or C<use> statement in 31a source stream, a new and distinct stream is created just for that 32file. 33 34The diagram below represents a single source stream, with the flow of 35source from a Perl script file on the left into the Perl parser on the 36right. This is how Perl normally operates. 37 38 file -------> parser 39 40There are two important points to remember: 41 42=over 5 43 44=item 1. 45 46Although there can be any number of source streams in existence at any 47given time, only one will be active. 48 49=item 2. 50 51Every source stream is associated with only one file. 52 53=back 54 55A source filter is a special kind of Perl module that intercepts and 56modifies a source stream before it reaches the parser. A source filter 57changes our diagram like this: 58 59 file ----> filter ----> parser 60 61If that doesn't make much sense, consider the analogy of a command 62pipeline. Say you have a shell script stored in the compressed file 63I<trial.gz>. The simple pipeline command below runs the script without 64needing to create a temporary file to hold the uncompressed file. 65 66 gunzip -c trial.gz | sh 67 68In this case, the data flow from the pipeline can be represented as follows: 69 70 trial.gz ----> gunzip ----> sh 71 72With source filters, you can store the text of your script compressed and use a source filter to uncompress it for Perl's parser: 73 74 compressed gunzip 75 Perl program ---> source filter ---> parser 76 77=head1 USING FILTERS 78 79So how do you use a source filter in a Perl script? Above, I said that 80a source filter is just a special kind of module. Like all Perl 81modules, a source filter is invoked with a use statement. 82 83Say you want to pass your Perl source through the C preprocessor before 84execution. As it happens, the source filters distribution comes with a C 85preprocessor filter module called Filter::cpp. 86 87Below is an example program, C<cpp_test>, which makes use of this filter. 88Line numbers have been added to allow specific lines to be referenced 89easily. 90 91 1: use Filter::cpp; 92 2: #define TRUE 1 93 3: $a = TRUE; 94 4: print "a = $a\n"; 95 96When you execute this script, Perl creates a source stream for the 97file. Before the parser processes any of the lines from the file, the 98source stream looks like this: 99 100 cpp_test ---------> parser 101 102Line 1, C<use Filter::cpp>, includes and installs the C<cpp> filter 103module. All source filters work this way. The use statement is compiled 104and executed at compile time, before any more of the file is read, and 105it attaches the cpp filter to the source stream behind the scenes. Now 106the data flow looks like this: 107 108 cpp_test ----> cpp filter ----> parser 109 110As the parser reads the second and subsequent lines from the source 111stream, it feeds those lines through the C<cpp> source filter before 112processing them. The C<cpp> filter simply passes each line through the 113real C preprocessor. The output from the C preprocessor is then 114inserted back into the source stream by the filter. 115 116 .-> cpp --. 117 | | 118 | | 119 | <-' 120 cpp_test ----> cpp filter ----> parser 121 122The parser then sees the following code: 123 124 use Filter::cpp; 125 $a = 1; 126 print "a = $a\n"; 127 128Let's consider what happens when the filtered code includes another 129module with use: 130 131 1: use Filter::cpp; 132 2: #define TRUE 1 133 3: use Fred; 134 4: $a = TRUE; 135 5: print "a = $a\n"; 136 137The C<cpp> filter does not apply to the text of the Fred module, only 138to the text of the file that used it (C<cpp_test>). Although the use 139statement on line 3 will pass through the cpp filter, the module that 140gets included (C<Fred>) will not. The source streams look like this 141after line 3 has been parsed and before line 4 is parsed: 142 143 cpp_test ---> cpp filter ---> parser (INACTIVE) 144 145 Fred.pm ----> parser 146 147As you can see, a new stream has been created for reading the source 148from C<Fred.pm>. This stream will remain active until all of C<Fred.pm> 149has been parsed. The source stream for C<cpp_test> will still exist, 150but is inactive. Once the parser has finished reading Fred.pm, the 151source stream associated with it will be destroyed. The source stream 152for C<cpp_test> then becomes active again and the parser reads line 4 153and subsequent lines from C<cpp_test>. 154 155You can use more than one source filter on a single file. Similarly, 156you can reuse the same filter in as many files as you like. 157 158For example, if you have a uuencoded and compressed source file, it is 159possible to stack a uudecode filter and an uncompression filter like 160this: 161 162 use Filter::uudecode; use Filter::uncompress; 163 M'XL(".H<US4''V9I;F%L')Q;>7/;1I;_>_I3=&E=%:F*I"T?22Q/ 164 M6]9*<IQCO*XFT"0[PL%%'Y+IG?WN^ZYN-$'J.[.JE$,20/?K=_[> 165 ... 166 167Once the first line has been processed, the flow will look like this: 168 169 file ---> uudecode ---> uncompress ---> parser 170 filter filter 171 172Data flows through filters in the same order they appear in the source 173file. The uudecode filter appeared before the uncompress filter, so the 174source file will be uudecoded before it's uncompressed. 175 176=head1 WRITING A SOURCE FILTER 177 178There are three ways to write your own source filter. You can write it 179in C, use an external program as a filter, or write the filter in Perl. 180I won't cover the first two in any great detail, so I'll get them out 181of the way first. Writing the filter in Perl is most convenient, so 182I'll devote the most space to it. 183 184=head1 WRITING A SOURCE FILTER IN C 185 186The first of the three available techniques is to write the filter 187completely in C. The external module you create interfaces directly 188with the source filter hooks provided by Perl. 189 190The advantage of this technique is that you have complete control over 191the implementation of your filter. The big disadvantage is the 192increased complexity required to write the filter - not only do you 193need to understand the source filter hooks, but you also need a 194reasonable knowledge of Perl guts. One of the few times it is worth 195going to this trouble is when writing a source scrambler. The 196C<decrypt> filter (which unscrambles the source before Perl parses it) 197included with the source filter distribution is an example of a C 198source filter (see Decryption Filters, below). 199 200 201=over 5 202 203=item B<Decryption Filters> 204 205All decryption filters work on the principle of "security through 206obscurity." Regardless of how well you write a decryption filter and 207how strong your encryption algorithm is, anyone determined enough can 208retrieve the original source code. The reason is quite simple - once 209the decryption filter has decrypted the source back to its original 210form, fragments of it will be stored in the computer's memory as Perl 211parses it. The source might only be in memory for a short period of 212time, but anyone possessing a debugger, skill, and lots of patience can 213eventually reconstruct your program. 214 215That said, there are a number of steps that can be taken to make life 216difficult for the potential cracker. The most important: Write your 217decryption filter in C and statically link the decryption module into 218the Perl binary. For further tips to make life difficult for the 219potential cracker, see the file I<decrypt.pm> in the source filters 220distribution. 221 222=back 223 224=head1 CREATING A SOURCE FILTER AS A SEPARATE EXECUTABLE 225 226An alternative to writing the filter in C is to create a separate 227executable in the language of your choice. The separate executable 228reads from standard input, does whatever processing is necessary, and 229writes the filtered data to standard output. C<Filter::cpp> is an 230example of a source filter implemented as a separate executable - the 231executable is the C preprocessor bundled with your C compiler. 232 233The source filter distribution includes two modules that simplify this 234task: C<Filter::exec> and C<Filter::sh>. Both allow you to run any 235external executable. Both use a coprocess to control the flow of data 236into and out of the external executable. (For details on coprocesses, 237see Stephens, W.R., "Advanced Programming in the UNIX Environment." 238Addison-Wesley, ISBN 0-210-56317-7, pages 441-445.) The difference 239between them is that C<Filter::exec> spawns the external command 240directly, while C<Filter::sh> spawns a shell to execute the external 241command. (Unix uses the Bourne shell; NT uses the cmd shell.) Spawning 242a shell allows you to make use of the shell metacharacters and 243redirection facilities. 244 245Here is an example script that uses C<Filter::sh>: 246 247 use Filter::sh 'tr XYZ PQR'; 248 $a = 1; 249 print "XYZ a = $a\n"; 250 251The output you'll get when the script is executed: 252 253 PQR a = 1 254 255Writing a source filter as a separate executable works fine, but a 256small performance penalty is incurred. For example, if you execute the 257small example above, a separate subprocess will be created to run the 258Unix C<tr> command. Each use of the filter requires its own subprocess. 259If creating subprocesses is expensive on your system, you might want to 260consider one of the other options for creating source filters. 261 262=head1 WRITING A SOURCE FILTER IN PERL 263 264The easiest and most portable option available for creating your own 265source filter is to write it completely in Perl. To distinguish this 266from the previous two techniques, I'll call it a Perl source filter. 267 268To help understand how to write a Perl source filter we need an example 269to study. Here is a complete source filter that performs rot13 270decoding. (Rot13 is a very simple encryption scheme used in Usenet 271postings to hide the contents of offensive posts. It moves every letter 272forward thirteen places, so that A becomes N, B becomes O, and Z 273becomes M.) 274 275 276 package Rot13; 277 278 use Filter::Util::Call; 279 280 sub import { 281 my ($type) = @_; 282 my ($ref) = []; 283 filter_add(bless $ref); 284 } 285 286 sub filter { 287 my ($self) = @_; 288 my ($status); 289 290 tr/n-za-mN-ZA-M/a-zA-Z/ 291 if ($status = filter_read()) > 0; 292 $status; 293 } 294 295 1; 296 297All Perl source filters are implemented as Perl classes and have the 298same basic structure as the example above. 299 300First, we include the C<Filter::Util::Call> module, which exports a 301number of functions into your filter's namespace. The filter shown 302above uses two of these functions, C<filter_add()> and 303C<filter_read()>. 304 305Next, we create the filter object and associate it with the source 306stream by defining the C<import> function. If you know Perl well 307enough, you know that C<import> is called automatically every time a 308module is included with a use statement. This makes C<import> the ideal 309place to both create and install a filter object. 310 311In the example filter, the object (C<$ref>) is blessed just like any 312other Perl object. Our example uses an anonymous array, but this isn't 313a requirement. Because this example doesn't need to store any context 314information, we could have used a scalar or hash reference just as 315well. The next section demonstrates context data. 316 317The association between the filter object and the source stream is made 318with the C<filter_add()> function. This takes a filter object as a 319parameter (C<$ref> in this case) and installs it in the source stream. 320 321Finally, there is the code that actually does the filtering. For this 322type of Perl source filter, all the filtering is done in a method 323called C<filter()>. (It is also possible to write a Perl source filter 324using a closure. See the C<Filter::Util::Call> manual page for more 325details.) It's called every time the Perl parser needs another line of 326source to process. The C<filter()> method, in turn, reads lines from 327the source stream using the C<filter_read()> function. 328 329If a line was available from the source stream, C<filter_read()> 330returns a status value greater than zero and appends the line to C<$_>. 331A status value of zero indicates end-of-file, less than zero means an 332error. The filter function itself is expected to return its status in 333the same way, and put the filtered line it wants written to the source 334stream in C<$_>. The use of C<$_> accounts for the brevity of most Perl 335source filters. 336 337In order to make use of the rot13 filter we need some way of encoding 338the source file in rot13 format. The script below, C<mkrot13>, does 339just that. 340 341 die "usage mkrot13 filename\n" unless @ARGV; 342 my $in = $ARGV[0]; 343 my $out = "$in.tmp"; 344 open(IN, "<$in") or die "Cannot open file $in: $!\n"; 345 open(OUT, ">$out") or die "Cannot open file $out: $!\n"; 346 347 print OUT "use Rot13;\n"; 348 while (<IN>) { 349 tr/a-zA-Z/n-za-mN-ZA-M/; 350 print OUT; 351 } 352 353 close IN; 354 close OUT; 355 unlink $in; 356 rename $out, $in; 357 358If we encrypt this with C<mkrot13>: 359 360 print " hello fred \n"; 361 362the result will be this: 363 364 use Rot13; 365 cevag "uryyb serq\a"; 366 367Running it produces this output: 368 369 hello fred 370 371=head1 USING CONTEXT: THE DEBUG FILTER 372 373The rot13 example was a trivial example. Here's another demonstration 374that shows off a few more features. 375 376Say you wanted to include a lot of debugging code in your Perl script 377during development, but you didn't want it available in the released 378product. Source filters offer a solution. In order to keep the example 379simple, let's say you wanted the debugging output to be controlled by 380an environment variable, C<DEBUG>. Debugging code is enabled if the 381variable exists, otherwise it is disabled. 382 383Two special marker lines will bracket debugging code, like this: 384 385 ## DEBUG_BEGIN 386 if ($year > 1999) { 387 warn "Debug: millennium bug in year $year\n"; 388 } 389 ## DEBUG_END 390 391The filter ensures that Perl parses the code between the <DEBUG_BEGIN> 392and C<DEBUG_END> markers only when the C<DEBUG> environment variable 393exists. That means that when C<DEBUG> does exist, the code above 394should be passed through the filter unchanged. The marker lines can 395also be passed through as-is, because the Perl parser will see them as 396comment lines. When C<DEBUG> isn't set, we need a way to disable the 397debug code. A simple way to achieve that is to convert the lines 398between the two markers into comments: 399 400 ## DEBUG_BEGIN 401 #if ($year > 1999) { 402 # warn "Debug: millennium bug in year $year\n"; 403 #} 404 ## DEBUG_END 405 406Here is the complete Debug filter: 407 408 package Debug; 409 410 use strict; 411 use warnings; 412 use Filter::Util::Call; 413 414 use constant TRUE => 1; 415 use constant FALSE => 0; 416 417 sub import { 418 my ($type) = @_; 419 my (%context) = ( 420 Enabled => defined $ENV{DEBUG}, 421 InTraceBlock => FALSE, 422 Filename => (caller)[1], 423 LineNo => 0, 424 LastBegin => 0, 425 ); 426 filter_add(bless \%context); 427 } 428 429 sub Die { 430 my ($self) = shift; 431 my ($message) = shift; 432 my ($line_no) = shift || $self->{LastBegin}; 433 die "$message at $self->{Filename} line $line_no.\n" 434 } 435 436 sub filter { 437 my ($self) = @_; 438 my ($status); 439 $status = filter_read(); 440 ++ $self->{LineNo}; 441 442 # deal with EOF/error first 443 if ($status <= 0) { 444 $self->Die("DEBUG_BEGIN has no DEBUG_END") 445 if $self->{InTraceBlock}; 446 return $status; 447 } 448 449 if ($self->{InTraceBlock}) { 450 if (/^\s*##\s*DEBUG_BEGIN/ ) { 451 $self->Die("Nested DEBUG_BEGIN", $self->{LineNo}) 452 } elsif (/^\s*##\s*DEBUG_END/) { 453 $self->{InTraceBlock} = FALSE; 454 } 455 456 # comment out the debug lines when the filter is disabled 457 s/^/#/ if ! $self->{Enabled}; 458 } elsif ( /^\s*##\s*DEBUG_BEGIN/ ) { 459 $self->{InTraceBlock} = TRUE; 460 $self->{LastBegin} = $self->{LineNo}; 461 } elsif ( /^\s*##\s*DEBUG_END/ ) { 462 $self->Die("DEBUG_END has no DEBUG_BEGIN", $self->{LineNo}); 463 } 464 return $status; 465 } 466 467 1; 468 469The big difference between this filter and the previous example is the 470use of context data in the filter object. The filter object is based on 471a hash reference, and is used to keep various pieces of context 472information between calls to the filter function. All but two of the 473hash fields are used for error reporting. The first of those two, 474Enabled, is used by the filter to determine whether the debugging code 475should be given to the Perl parser. The second, InTraceBlock, is true 476when the filter has encountered a C<DEBUG_BEGIN> line, but has not yet 477encountered the following C<DEBUG_END> line. 478 479If you ignore all the error checking that most of the code does, the 480essence of the filter is as follows: 481 482 sub filter { 483 my ($self) = @_; 484 my ($status); 485 $status = filter_read(); 486 487 # deal with EOF/error first 488 return $status if $status <= 0; 489 if ($self->{InTraceBlock}) { 490 if (/^\s*##\s*DEBUG_END/) { 491 $self->{InTraceBlock} = FALSE 492 } 493 494 # comment out debug lines when the filter is disabled 495 s/^/#/ if ! $self->{Enabled}; 496 } elsif ( /^\s*##\s*DEBUG_BEGIN/ ) { 497 $self->{InTraceBlock} = TRUE; 498 } 499 return $status; 500 } 501 502Be warned: just as the C-preprocessor doesn't know C, the Debug filter 503doesn't know Perl. It can be fooled quite easily: 504 505 print <<EOM; 506 ##DEBUG_BEGIN 507 EOM 508 509Such things aside, you can see that a lot can be achieved with a modest 510amount of code. 511 512=head1 CONCLUSION 513 514You now have better understanding of what a source filter is, and you 515might even have a possible use for them. If you feel like playing with 516source filters but need a bit of inspiration, here are some extra 517features you could add to the Debug filter. 518 519First, an easy one. Rather than having debugging code that is 520all-or-nothing, it would be much more useful to be able to control 521which specific blocks of debugging code get included. Try extending the 522syntax for debug blocks to allow each to be identified. The contents of 523the C<DEBUG> environment variable can then be used to control which 524blocks get included. 525 526Once you can identify individual blocks, try allowing them to be 527nested. That isn't difficult either. 528 529Here is an interesting idea that doesn't involve the Debug filter. 530Currently Perl subroutines have fairly limited support for formal 531parameter lists. You can specify the number of parameters and their 532type, but you still have to manually take them out of the C<@_> array 533yourself. Write a source filter that allows you to have a named 534parameter list. Such a filter would turn this: 535 536 sub MySub ($first, $second, @rest) { ... } 537 538into this: 539 540 sub MySub($$@) { 541 my ($first) = shift; 542 my ($second) = shift; 543 my (@rest) = @_; 544 ... 545 } 546 547Finally, if you feel like a real challenge, have a go at writing a 548full-blown Perl macro preprocessor as a source filter. Borrow the 549useful features from the C preprocessor and any other macro processors 550you know. The tricky bit will be choosing how much knowledge of Perl's 551syntax you want your filter to have. 552 553=head1 LIMITATIONS 554 555Source filters only work on the string level, thus are highly limited 556in its ability to change source code on the fly. It cannot detect 557comments, quoted strings, heredocs, it is no replacement for a real 558parser. 559The only stable usage for source filters are encryption, compression, 560or the byteloader, to translate binary code back to source code. 561 562See for example the limitations in L<Switch>, which uses source filters, 563and thus is does not work inside a string eval, the presence of 564regexes with embedded newlines that are specified with raw C</.../> 565delimiters and don't have a modifier C<//x> are indistinguishable from 566code chunks beginning with the division operator C</>. As a workaround 567you must use C<m/.../> or C<m?...?> for such patterns. Also, the presence of 568regexes specified with raw C<?...?> delimiters may cause mysterious 569errors. The workaround is to use C<m?...?> instead. See 570L<https://metacpan.org/pod/Switch#LIMITATIONS>. 571 572Currently the content of the C<__DATA__> block is not filtered. 573 574Currently internal buffer lengths are limited to 32-bit only. 575 576 577=head1 THINGS TO LOOK OUT FOR 578 579=over 5 580 581=item Some Filters Clobber the C<DATA> Handle 582 583Some source filters use the C<DATA> handle to read the calling program. 584When using these source filters you cannot rely on this handle, nor expect 585any particular kind of behavior when operating on it. Filters based on 586Filter::Util::Call (and therefore Filter::Simple) do not alter the C<DATA> 587filehandle, but on the other hand totally ignore the text after C<__DATA__>. 588 589=back 590 591=head1 REQUIREMENTS 592 593The Source Filters distribution is available on CPAN, in 594 595 CPAN/modules/by-module/Filter 596 597Starting from Perl 5.8 Filter::Util::Call (the core part of the 598Source Filters distribution) is part of the standard Perl distribution. 599Also included is a friendlier interface called Filter::Simple, by 600Damian Conway. 601 602=head1 AUTHOR 603 604Paul Marquess E<lt>Paul.Marquess@btinternet.comE<gt> 605 606Reini Urban E<lt>rurban@cpan.orgE<gt> 607 608=head1 Copyrights 609 610The first version of this article originally appeared in The Perl 611Journal #11, and is copyright 1998 The Perl Journal. It appears 612courtesy of Jon Orwant and The Perl Journal. This document may be 613distributed under the same terms as Perl itself. 614