(
 '4a4a2bfe01ac410d0105f4fd0dae30150dfab448f90208fa0d98;pop',
 'pop;pop',
 'print+chr(shift);pop',
 'print+chr(shift);pop',
 'unshift@_,(shift()+shift())x2;pop',
 'push@_,(pop,pop)x24;pop',
 ';;pop',
 'unshift@_,(map{unpack'c',$_}split//)[0..25];pop',
 ';;pop',
 's/../chr(hex$&)/eg;pop',
);
##</code><code>##

# Umm, let's write that hex string in bytepairs...
# 4a 4a 2b fe 01 ac 41 0d 01 05 f4 fd 0d ae 30 15
# 0d fa b4 48 f9 02 08 fa 0d 98

##</code><code>##

 4a  4a  2b  fe  01  ac  41  0d  01  05  f4  fd  0d
 74  74  43  -2   1 -84  65  13   1  5  -12  -3  13

 ae  30  15  0d  fa  b4  48  f9  02  08  fa  0d  98
-82  48  21  13  -6 -76  72  -7   2   8  -6  13 -104

##</code><code>##

# 'unshift@_,(shift()+shift())x2;pop',
# 'print+chr(shift);pop'

# Apparently we construct an anonymous list out of those, repeat it 24
# times, and push it (flattened, presumably) onto the tail end of @_.
# This means that the next 48 instructions (err, 49) will be those two
# instructions alternating.  Since the first is pushed first, the
# second will be popped first.  Also last since It's repeated again
# just above the two instructions we popped off to repeat.

# WTF is that doing?

# Okay, break it down...
# print with no args prints $_ on STDOUT and returns... what?
# [consults Camel]
# print returns 1 if successful, 0 otherwise.
# So we're printing $_, removing the next char from the
# beginning of @_, taking its numeric value, adding one
# to it (or possibly 0, but I think 1), and... throwing
# that value away?  What?

# Also, what's on $_?  Isn't it still the messy unprocessed ASCII
# version of those hex data?  I thought we were done with that after
# we converted it and threw the result on @_?  But here we're throwing
# away the converted data from @_ and going back to (repeatedly)
# printing $_?

# HUH?

# [Consults camel]
# [Consults camel more]
# [Consults camel yet more]
# Losted am I.