Mass find/replace...

Mel fbsd.questions at rachie.is-a-geek.net
Fri Dec 5 01:39:24 PST 2008


On Friday 05 December 2008 10:17:46 Marc Coyles wrote:
> > + not \; or you will fork on every result.
> >
> > Additionally, is this injected code one long string or broken down
> > by the
> > mailer? Grep isn't the best way to deal with it. It's pretty easy
> > to correct
> > with perl, bit trickier if it's multiline, still not too hard:
> >
> > find /home/horbury -type f -exec \
> > 	perl -pi.bak -e 's,<\? /\*\*/eval\(base64_decode\(.*?\?>,,s' {} +
>
> Sadly that didn't work. It created .bak files for everything within
> /home/Horbury recursively, but didn't make any changes - the base64_decode
> is till present.
>
> Additional point to note: this only needs performing on .php files, not all
> files...
>
> Would I be correct in guessing it's because the string for perl to search
> for omits a space?

Nope.

> IE: within the files, it's as follows:
> <?php /**/eval(base64_decode('thestring')); ?>

Cause in your original mail I didn't catch the <?php, but the shorthand open. 
So it should be:

's,<\?php /\*\*/eval\(base64_decode\(.*?\?>,,s'

> Whereas the perl appears to be looking for:
> <?php/**/eval(base64_decode(*wildcard*?>
>
> Also... how to delete all files ending in .bak recursively? *grin*
>
> I'm presuming it'd be:
>
> Find /home/horbury -type f -name "*.bak" -exec \

find /home/horbury -name '*.bak' -delete

-- 
Mel

Problem with today's modular software: they start with the modules
    and never get to the software part.


More information about the freebsd-questions mailing list