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