RE: RE: RE: Obfuscate my perl code
by Fastolfe (Vicar) on Oct 27, 2000 at 18:39 UTC
|
Doubtful.. I would imagine they run just the same. If all you're doing is changing the appearance of the code, variable names, etc., the parser isn't going to have any problem with it, and the resulting bytecode will be indistinguishable. If, however, you're encoding your strings, doing some unusual looping or whatever, you're going to incur some slight penalties if a lot of work normally done at compile time is going to be done (esp. repetitively) at run-time. It all depends on how you go about doing it. | [reply] [Watch: Dir/Any] |
|
This was my thought as well, but some cool tricks look to me somewhat like obfuscated.
So I might redefine: How obfuscated is effective perl?
Have a nice day
All decision is left to your taste
| [reply] [Watch: Dir/Any] |
|
Depends on your definition of 'effective'. If you're writing for readability and maintainability, I would say that an effective Perl script isn't obfuscated at all. If you're wanting to take advantage of some efficiency tricks via map and complex data structures (via references), your code becomes slightly harder to read. If you're making use of aliasing and other "magic", things become harder still, but with ample documentation and consistent style, none of this has to appear obfuscated.
| [reply] [Watch: Dir/Any] |
YES! I do
by Nitsuj (Hermit) on Oct 29, 2000 at 02:47 UTC
|
Ever read any really highly optimized code? In assmebly perhaps? Some methods like intentionally overflowing, stuff like that? Passing pointers in odd ways. Lots of stuff like that makes code almost unreadable, but can make it MUCH faster. Look at the goto statement! I have heard of old computers that move through data structures quickly by cycling to the end of drum memory, and then cycling foward one to arrive at the head again. Try a full time job maintaining old code, designed on old machines. Almost impossibly to read, but HIGHLY tuned and INCREDIBLY efficient. They used to fit everything in less than 16K on high end computers, and did some pretty crazy cramming to make it work.
Just Another Perl Backpacker | [reply] [Watch: Dir/Any] |
|
I can't vouch for the accuracy of Mel in the aforementioned story, but I can tell you that drum tuning was a *very* common practice. Other than Mel getting the sense switch backwards, all the tuning information is probable.
There are a couple of machines that have some really cool instructions. The old Data General Nova systems had an indexed fetch instruction that if the high bit was set, would use the contents of the fetched data as another index. If the high bit was set, this would repeat. It made finding the end of a linked list pretty trivial. It could also make a pretty effective endless loop. With the Nova 1200 system we... acquired... we taught it to play the "Daisy, Daisy, Give me your answer true" melody by tuning loops that made the core memory planes "sing". If I run across my 8K x 16 core memory plane, I'll take a picture and post it. Hand woven by oriental women.
Another interesting instruction was on the Control Data Corporation Cyber systems. At the request of the Atomic Energy Comission, an instruction was added that would return the number of bits set it a word (these were 60 bit words). This was used in some nuclear bomb simulation calcuations.
One free ++ to anyone who figures out what this code does, and explains why:
and al,00fh
add al,090h
daa
adc al,040h
daa
The actual instruction set is irrelevant, but that's x86 code.
--Chris
e-mail jcwren | [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] |
|
i was always one for a challenge:
perhaps this is a newbie asm question but I always thought al/ah were 8 bit registers- is this my old asm experience talking? could it be the "new" intel "standards". hmmmmm....well, I've seen stranger Mac asm, so, for the challenge, I'll assume 24 bit registers, I guess....
I just followed my thoughts through- here they are:
- and al,00fh: sets first 16 bits of al to 0, last 8 bits are left as they were
- add al,090h: adds one gross (144=9*16) to al, which makes al now 09x where x is from the original set
- daa: decimal adjust after addition: changes al to a packed decimal number stored in hex- results in 90+x as decimal packed into hex
- adc al,040h: adds dest to src and carry flag, too: (90h+xh)+40h
- daa: like (90+40)+x=130+x packed BCD
hmmm, can this be right? probably not, oh well. I find it amusing that CISC processing leads to infinite obfuscation- much more than perl could ever achieve. (www.assemblymonks.org?)
/me decides that perl is better than assembly.
AgentM Systems nor Nasca Enterprises nor
Bone::Easy nor Macperl is responsible for the
comments made by
AgentM. Remember, you can build any logical system with NOR.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
There was a PDP11 instruction that copied it's own code (yeah, there are a lot of processors with this instruction). Anyways, they cut HUGE amounts of code in the Personal Rapid Transit Project using this instruction (as I alluded to in my other post, but they did some other crazy stuff too)!
Just Another Perl Backpacker
| [reply] [Watch: Dir/Any] |
|
this is just haker's folklore, maybe you was too impressed by
this story...
| [reply] [Watch: Dir/Any] |
|
It's not entirely folklore. We used to do this sort of thing
all the time in the AppleII and 64KB PC days. Heck I used
to have a switch construct in PC assembler that pushed the
the segment and instruction pointer to stack, added a few bytes,
then pushed a destination onto the stack and did an IRET.
The routines it jumped to did an IRET to come back. I saved
like 24 bytes by doing it "wrong" and basically broke any
disassembler out there. Also, it was faster... =)
Evil self-modifying code was the only way you could
get anything to work in non-glacial speed on the Apple.
My friend Rick wrote an 8 direction generalized 8x8 pixel
block move that self modified itself in a tight loop.
It could smoothly move about 50 cells of 8x8 tiles faster
than the screen refresh and was about 130ish bytes. The
original way had taken over a 1k and he wanted more room
for tiles. And yes, we explored modifying the code a bit
to use it as graphic tiles first. =)
Writing in a memory budget was terrific for helping you
think outside the box...
--
$you = new YOU;
honk() if $you->love(perl)
| [reply] [Watch: Dir/Any] |
|
I know that they saved a lot of memory by using what some would consider some very odd tricks, in the programming of the Personal Rapid Transit, which is the transportation system at my university (West Virginia University). You would be surprised how much info they squeezed into some VERY tight space.
Just Another Perl Backpacker
| [reply] [Watch: Dir/Any] |