It refers to things like software that reads documentation, reverse engineers code running on the target system, works backwards from the target CPU manual and compiler toolchain to make object code that runs on the CPU, and generally does what a human does when porting code to run on another system possibly without a compiler and take advantage of flaws on the target.

I think we're half way there already, because of the number of tools for decompiling and code scanning for security vectors these days, the increasing use of fuzzers to discover unintended or undocumented features, including hardware features like undocumented instructions, and increasingly clever and subtle side-channel attacks for finding device state that is not supposed to be visible to software.

Also, if it can happen by accident then I don't really think it should be called "porting". You don't find that a linux-centric malware has "accidentally" "ported" itself to windows, likewise Intel bytecode doesn't suddenly execute on ARM chips.

The difference between "porting" and "modifying" has (at least in everything I've read in "hacker" culture) always been that porting is rarely a trivial act.

I suppose in theory malware that targets dev tools and source to infect compiled code could end up getting ported along with it’s target. More hitching a ride than porting itself though.