more useful options | |
PerlMonks |
Re: Fun with duff's device and AUTOLOADby ambrus (Abbot) |
on Feb 24, 2004 at 21:30 UTC ( [id://331531]=note: print w/replies, xml ) | Need Help?? |
Now I've got 3 different reports that the script does not work. Someone said it even did not work on Solaris. I can not reproduce the bad behaivior so it will be difficult to track down the bug, especially because it seems to run on most machines. (Update @ 2006 may 24: it seems I could finally reproduce the error on a machine. I'll try to investigate it if I have time.) I'll however explain where I've got the numbers and why they translate to a sensible message. I've got the basic idea after the thread $#="%c"; possible bug. The trick is that $#="%c"; print 3.14; is entirely unlike printf "%c", 3.14;. Just try $#="%d"; print 10;! It does not print 10, rather, it prints 0 (i386) or some stupid number depending on the endianndess of your cpu. This is because when formatting numbers a la $#, perl calls sprintf (or some equivalent) with $# as a format and the number as a floating point number to the stack. I don't know where this is in the source, probably hidden somewhere in sv.c, but I'm quite sure it works like this. Update: I'd be glad if someone could point me to the guilty code. The floating-point numbers are given so that when represented as a double, their upper and lower 4 bytes are both the same small integer, the ascii code of a character in the message. I had to put the same integer twice, so that the code would work in both intel-endian and sparc-endian cpu's. Really, if you consider only one kind of cpus, half as much numbers would have been enough. Let me show this. Type perl -we 'print join ", ", unpack "d*", pack "l*", unpack "c*", "perl"; print $/;'. This prints (on intel) 2.14321574942828e-312, 2.29175545480573e-312. Now using this numbers you can write perl -we '$#="%c%c"; print 2.14321574942828e-312, 2.29175545480573e-312; print $/;', which prints perl. I created the obfu in a very similar way. The problem is that all this will fail if your perl was compiled with long double support, as the floating point format is quite different. There may be other problems why the script did not run for some people, which I currently don't know. Please check that your perl is not compiled with long doubles. Just run use Config; print qq[@Config{"nvtype","nvsize"}\n]; if it prints double 8, that is good. If it prints long double 12, the obfu will not work. There may also be issues about 64-bitness, I can not check that. Note that I have not tried the obfu from Windows, but in theory it should work.
In Section
Obfuscated Code
|
|