Pith. sign in

REVIEW 2 major objections 4 minor 24 references

RISC-V: #AlphanumericShellcoding

T0 review · 2 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper demonstrates that RISC-V systems can be made to execute arbitrary code from shellcodes restricted to alphanumeric ASCII characters plus one of #, /, or ', and validates the approach with three payloads on an emulator and a…

desk verdict First working RISC-V alphanumeric shellcodes with real-hardware validation; the tick variant's unproven solver is the main soft spot, but the hash and slash routes stand. read the letter →

arxiv 1908.03819 v1 pith:HVFGX6EL submitted 2019-08-10 cs.CR

Hadrien Barral , Rémi Géraud-Stewart , Georges-Axel Jaloyan , David Naccache This is my paper · ORCID
classification cs.CR
keywords alphanumericshellcodeRISC-Vgenerationpackingexploitdevelopmentfloating-pointencodingASCIIpayloadtext-basedfilterbypass
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper establishes that RISC-V, a young open-source instruction set heading into embedded devices, is vulnerable to alphanumeric shellcoding: a short injected program whose binary representation uses only letters a–z, A–Z, digits 0–9, and one extra character chosen from #, /, or '. The authors build a three-stage packing framework—an unrolled first-stage unpacker, a tiny looping decoder, and the final payload—that turns arbitrary compiled C code into such an ASCII-restricted shellcode. This matters because text-based applications (SMS, chat, URLs, QR codes) commonly filter out binary-looking bytes, and RISC-V has had no published alphanumeric shellcode analysis before this paper. The claim is backed by executing three payloads (a 'Hello world' write, an execve('/bin/sh') spawn, and an /etc/shadow leak) on QEMU and on a HiFive Unleashed board running Linux.

What carries the argument

The mechanism that carries the argument is the three-stage packer combined with a precomputed load table and a 4-bit-per-byte XOR decoder. Stage 1's load table is built by depth-first search over the # alphanumeric subset and yields shortest sequences for 63,448 of 65,536 possible 16-bit values, enough to write any needed stage-2 instruction into memory two bytes at a time. The decoder itself is the identity $A[0:3] = L[0:3] \oplus L[4:7]$, $A[4:7] = K[0:3] \oplus L[4:7]$, with a closed-form rule choosing alphanumeric $K$ and $L$ for every byte $A$; this keeps the loop to five instructions. For the tick variant, the store is replaced by floating-point fused-multiply-add equations $r = a \times b + c$, and Algorithm 1 searches over roughly six million register-renamed or reordered stage-2 instances until all equations have alphanumeric solutions.

What would settle it

Run the paper's own generator on a fixed 512-byte payload and let Algorithm 1 test every stage-2 instance; if every instance leaves some equation unsolved, the tick variant cannot encode that payload and the 'arbitrary payload' claim fails for this construction.

Watch

Extended reading notes

Core claim

The central claim is that RV64GC's alphanumeric instruction subset, although it contains no stores and no backward jumps, is expressive enough for arbitrary code execution through packing. Stage 1 is a straight-line unpacker that uses the one allowed extra character to obtain a store instruction (sw/sd for #, amoor.d for /, or fsd for ') and writes a minimal stage 2 into memory next to itself. Stage 2, only 40 bytes long, runs a five-instruction loop that decodes two alphanumeric bytes into one payload byte and jumps to the decoded payload after a fence.i cache flush. The authors present this as the first analysis of alphanumeric code on RISC-V and the first complete framework for automatically generating such shellcodes, with all three constructions executed on a real board.

Load-bearing premise

The floating-point variant's load-bearing premise is that at least one register-renamed or reordered instance of stage 2 satisfies every equation $r = a \times b + c$ with alphanumeric $a,b,c$; the authors find such instances by search and give no proof that one exists for every payload.

Editorial extensions

If this is right

  • An input sanitizer that keeps only letters, digits, and one of #, /, or ' still leaves a RISC-V process open to arbitrary code execution.
  • The three-stage packer runs end to end from C source, so a new RISC-V payload does not require hand-written assembly; the same skeleton can be reused across the three constructions.
  • The 4-bit-per-byte encoding keeps the decoder to five instructions and stage 2 to 40 bytes, so the practical size of a shellcode is dominated by the encoded payload, which is demonstrated up to the 512-byte cap.
  • The absence of backwards branches in the base alphanumeric subset is not a blocker: stage 1 is a straight-line unrolled unpacker that jumps forward over the payload pool.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A reader could reasonably infer that RISC-V text-processing applications (URL, SMS, chat, QR-code handlers) inherit a new injection surface: printable-looking content should be treated as executable data, not inert text.
  • The floating-point variant's reliance on search rather than proof suggests an adversarial stress test: choose a payload designed so every polymorphic stage-2 instance leaves an unsolvable equation; success would show the tick route is not universal.
  • The 63-symbol alphabet could in principle encode nearly six bits per byte, so a denser encoder than the paper's four-bit scheme would make shellcodes shorter at the cost of a longer decoder, a trade-off the paper leaves for future work.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 4 minor

Summary. The paper presents a methodology for constructing RISC-V shellcodes whose binary representation contains only alphanumeric ASCII characters plus one additional character: '#', '/', or '''. The construction is three-staged: a first-stage unpacker written in a highly constrained alphanumeric instruction subset unpacks a second-stage decoder, which in turn decodes and executes an arbitrary third-stage payload. The authors enumerate the available alphanumeric instructions in the RV64GC ISA, give a table-based method for loading arbitrary 2-byte values in the '#RV64IC' and '/RV64IAC' variants, and use floating-point fused-multiply-add equations in the '''RV64IDC' variant. They report successful execution of three payloads (printf/write "Hello world", execve("/bin/sh"), and an /etc/shadow leak) on both QEMU and a HiFive Unleashed board, and provide the generated shellcodes in the appendix.

Significance. If the results hold, this is the first published construction of alphanumeric shellcode for RISC-V and a useful extension of the ARMv8 methodology from Barral et al. The paper's strengths include real-hardware validation on a HiFive Unleashed board, reproducibly printed shellcodes, and a publicly available toolchain with three distinct variants. The central packing design is sound, and the hash and slash variants are demonstrated with deterministic store/atomic instruction sequences. However, the abstract's 'complete framework' wording overstates what is proved for the tick variant, whose solvability depends on an unproven heuristic search.

major comments (2)
  1. [Section 5.6, Algorithm 1] The completeness of the '''RV64IDC variant rests on an unproven existence assumption. The text explicitly states that the floating-point equations ri = ai*b + ci are 'not guaranteed to always have solutions' and that the authors generate polymorphic stage-2 instances 'hoping to find one' for which all equations are solvable. Algorithm 1 has no termination proof, and the reported 2.3e11-iteration run with an ad hoc 2,000,000-iteration cap does not provide coverage over the roughly 6 million polymorphic instances. Since the abstract promises 'a complete framework' for automatic generation of shellcodes for arbitrary code, this is a load-bearing gap. The authors should either prove or analytically bound the existence of at least one solvable stage-2 instance for any payload, or explicitly qualify the completeness claim as conditional on the randomized search succeeding for the payload at hand.
  2. [Section 5.1.3 and Section 5.5] The 2-byte-load table covers only 96% of possible 16-bit values for '#RV64IC' and 88% for '/RV64IAC'. For the claimed 'complete framework', the paper must explain how the generator guarantees that every 16-bit chunk of stage 2 lies in the supported set. The text only states that stage 2 is designed 'so that every pair of bytes in stage 2 could be loaded from an instruction sequence in the table' and reports success for the three demonstration payloads. This is not a defect in the demonstrated artifacts, but it is another point where the word 'complete' exceeds what is formally established.
minor comments (4)
  1. [Abstract] The phrase 'whose ASCII binary representation use only' should be 'whose ASCII binary representation uses only', and the term 'alphanumeric (+1 character)' should be defined at its first occurrence.
  2. [Section 6.2] The empirical validation would be more useful if the paper stated whether NX/DEP or other executable-memory protections were disabled on the HiFive test environment, since the attack assumes executable memory for the unpacked shellcode.
  3. [Section 5.6] The statement that the search required '1.5 execution hours' on a 4-core Atom 2GHz CPU should specify whether this is wall-clock time or CPU time, especially since Algorithm 1 is described as parallelized.
  4. [Appendix A] The shellcode listings rely on color coding that is not reproducible in print; a textual annotation or a table mapping each colored region to its high-level role would make the appendix self-contained.

Circularity Check

0 steps flagged · score 2.0 of 10

No load-bearing circularity: the three RISC-V alphanumeric shellcode constructions are derived from an explicit instruction enumeration and validated externally on QEMU and HiFive Unleashed hardware; the only self-citation, to the ARMv8 methodology [3], is lineage, not a derivation input.

full rationale

I walked the paper's claimed derivation chain and found no step where a derived quantity is identical to an input by construction or where a fitted parameter is relabeled as a prediction. Section 3 constructs alpha_RV64GC by exhaustively disassembling every candidate alphanumeric 16- and 32-bit word with objdump, an external ISA oracle; the subsequent instruction inventory is data, not an assumption. Stage 1 (Section 5.1) uses a precomputed table of shortest load sequences for 2-byte immediates, generated by a stated bounded depth-first search with a stated 96% coverage; the table is used to assemble stage 2, not to predict it. Stage 2's decoding equations (Section 5.2) are solved explicitly: the paper derives an alphanumeric K/L encoding for every byte A and verifies it by substitution, so this is a construction, not a self-fulfilling fit. The three variants were executed successfully on QEMU and on a HiFive Unleashed board running Linux, with three independent payloads, which is external validation of the central claim. The self-citation to Barral et al. [3] appears only as a clustering convention and as an argument that the methodology is generic; the RISC-V-specific selection, unpacker layout, and encodings are derived in this paper, so the citation is not load-bearing. The tick variant (Section 5.6) is the nearest thing to a gap: the floating-point equations are not guaranteed solvable and Algorithm 1 is an existence search that the paper describes as 'hoping to find' a solvable polymorphic instance. That is an honest completeness caveat about arbitrary new payloads, not a circularity, because the demonstrated payloads were actually solved and executed rather than assumed. I therefore report no significant circularity; the minor self-citation keeps this in the 0-2 range rather than 0.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

The central constructions rest on ISA encoding facts, an executable-memory threat model, a cache coherence assumption for self-modifying code, FPU availability, and the existence of floating-point equation solutions for one variant. No free parameters or invented entities are introduced; the engineering choices (4-bit encoding, 512-byte payload bound, three-stage design) are design decisions rather than fitted values.

assumptions (6)
  • domain assumption RISC-V RV64GC instruction encoding constraints: 16-bit instructions have the two LSBs 00/01/10; 32-bit instructions have LSBs bbb11 with bbb not equal to 111.
    Used in Section 3 to filter and enumerate the alphanumeric instruction subset alphaRV64GC via objdump.
  • domain assumption The target application executes attacker-supplied input as code in an executable memory region.
    Section 6.2 creates 'a purposely vulnerable application executing its input data', which sidesteps NX/DEP protections that would block execution of the unpacked payload.
  • ad hoc to paper The first fence.i instruction in stage 2 is not shadowed in the instruction cache.
    Explicitly raised in Section 5.2 ('We discuss later in Section 6 the assumption that the first fence.i is not shadowed') and reported as not observed in practice on the test hardware.
  • domain assumption The FPU is activated in hosted environments for the 'RV64IDC variant.
    Section 5.6: 'it requires the floating-point unit (FPU) to be activated, which is always done by the operating system when working in a hosted environment'.
  • ad hoc to paper For 'RV64IDC, a solution to the floating-point encoding equation set exists for some polymorphic stage 2 instance.
    Section 5.6 and Algorithm 1 search for such an instance, with 2.3e11 iterations counted, but no proof of existence for arbitrary payloads is given.
  • standard math All bytes of the form 0x4* and 0x6* with non-null low nibble are alphanumeric ASCII.
    Used in Section 5.2 to construct the 4-bit-per-byte encoding; follows directly from the ASCII table.

how reviews work

0 comments
Cite this review

Pith. "Pith review of RISC-V: #AlphanumericShellcoding." pith.science (2026). https://pith.science/paper/HVFGX6EL

@misc{pith2026190803819,
  author       = {Pith},
  title        = {Pith review of: RISC-V: #AlphanumericShellcoding},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HVFGX6EL}},
  note         = {Machine review of arXiv:1908.03819}
}
read the original abstract

We explain how to design RISC-V shellcodes capable of running arbitrary code, whose ASCII binary representation use only letters a-zA-Z, digits 0-9, and either of the three characters: #, /, '.

Figures

Figures reproduced from arXiv: 1908.03819 by the authors.

Figure 1
Figure 1. General structure of stage 1: an initialization section, with a [PITH_FULL_IMAGE:figures/full_fig_p010_1.png] view at source ↗
Figure 2
Figure 2. General structure of stage 2: an initialization section, with a [PITH_FULL_IMAGE:figures/full_fig_p011_2.png] view at source ↗
Figure 3
Figure 3. Diagram of a 16-byte block. Our stage 2 instructions are located [PITH_FULL_IMAGE:figures/full_fig_p016_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

24 extracted references · 22 canonical work pages

  1. [1]

    ARM Architecture Reference Manual

    ARMLimited. ARM Architecture Reference Manual. ARMv8, for ARMv8- A architecture profile. 110 Fulbourn Road, Cambridge, England, 2013. url: https://static.docs.arm.com/ddi0487/da/DDI0487D_a_ armv8_arm.pdf

    work page 2013

  2. [2]

    AVR Instruction Set Manual.1600TechnologyDrive,SanJose, USA, 2016

    Atmel. AVR Instruction Set Manual.1600TechnologyDrive,SanJose, USA, 2016. url: http://ww1.microchip.com/downloads/en/ devicedoc/atmel-0856-avr-instruction-set-manual.pdf

    work page 2016

  3. [3]

    ARMv8 Shellcodes from ‘A’to ‘Z’

    Hadrien Barral et al. “ARMv8 Shellcodes from ‘A’to ‘Z’”. In:Pro- ceedings of the 12th International Conference on Information Security Practice and Experience. Berlin, Heidelberg: Springer-Verlag, 2016, pp. 354–377.isbn: 978-3-319-49151-6.url:https://link.springer. com/chapter/10.1007/978-3-319-49151-6_25. 20

    work page doi:10.1007/978-3-319-49151-6_25 2016

  4. [4]

    Automatic Generation of Compact Alphanumeric Shellcodes for x86

    Aditya Basu, Anish Mathuria, and Nagendra Chowdary. “Automatic Generation of Compact Alphanumeric Shellcodes for x86”. In:Pro- ceedings of the 10th International Conference on Information Systems Security. Berlin, Heidelberg: Springer-Verlag, 2014, pp. 399–410.isbn: 978-3-319-13841-1. url: https://doi.org/10.1007/978-3-319- 13841-1\_22

    doi:10.1007/978-3-319- 2014

  5. [5]

    QEMU, a Fast and Portable Dynamic Translator

    Fabrice Bellard. “QEMU, a Fast and Portable Dynamic Translator”. In: Proceedings of the 2005 USENIX Annual Technical Conference. Berkeley,CA,USA:USENIXAssociation,2005,pp.41–46. url:https: //www.cse.iitd.ernet.in/~sbansal/csl862-virt/2010/readings/ bellard.pdf

    work page 2005

  6. [6]

    RISC-V ELF psABI Specifcation

    Palmer Dabbelt et al. RISC-V ELF psABI Specifcation. 2016. url: https://github.com/riscv/riscv-elf-psabi-doc/

    work page 2016

  7. [7]

    Debian Wiki. RISC-V. 2019. url: https://wiki.debian.org/RISC- V

    work page 2019

  8. [8]

    mov is Turing-Complete

    Stephen Dolan. mov is Turing-Complete. 2013. url: https://www. cl.cam.ac.uk/~sd601/papers/mov.pdf

    work page 2013

Show all 24 references
  1. [9]

    The M/o/Vfuscator

    Christopher Domas. The M/o/Vfuscator. 2015.url: https://recon. cx/2015/slides/recon2015-14-christopher-domas-The-movfuscator. pdf

    2015

  2. [10]

    Bypassing MSB data filters for buffer overflow exploits on Intel platforms

    Riley Eller. Bypassing MSB data filters for buffer overflow exploits on Intel platforms. 2000. url: https://web.archive.org/web/ 20070221035114/community.core-sdi.com/~juliano/bypass- msb.txt

    2000

  3. [11]

    Power ISA Version 3.0B.2017

    IBM. Power ISA Version 3.0B.2017. url:https://openpowerfoundation. org/?resource_lib=power-isa-version-3-0

    2017

  4. [12]

    English Shellcode

    Joshua Mason et al. “English Shellcode”. In:Proceedings of the 16th ACM Conference on Computer and Communications Security. New York, NY: ACM, 2009, pp. 524–533.isbn: 978-1-60558-894-0. url: https://doi.org/10.1145/1653662.1653725

    2009

  5. [13]

    NX: How well does say No to an attackers eXecution attempts? 2005

    David Maynor. NX: How well does say No to an attackers eXecution attempts? 2005. url: https://www.blackhat.com/presentations/ bh-usa-05/bh-us-05-maynor.pdf

    2005

  6. [14]

    Higher Subleq: Compiler into OISC language

    Oleg Mazonka. Higher Subleq: Compiler into OISC language. 2009. url: http://mazonka.com/subleq/hsq.html. 21

    2009

  7. [15]

    Microsoft Security Toolkit Delivers New BlueHat Prize De- fensive Technology

    Microsoft. Microsoft Security Toolkit Delivers New BlueHat Prize De- fensive Technology. 2012. url: https://news.microsoft.com/2012/ 07/25/microsoft-security-toolkit-delivers-new-bluehat- prize-defensive-technology/

    2012

  8. [16]

    MIPS32 Architecture For Programmers

    MIPS Technologies, Inc. MIPS32 Architecture For Programmers. Vol- ume II: The MIPS32 Instruction Set. 2001. url: https://www.cs. cornell.edu/courses/cs3410/2008fa/MIPS_Vol2.pdf

    2001

  9. [17]

    RISCI:Areducedinstruction set VLSI computer

    DavidAPattersonandCarloHSequin.“RISCI:Areducedinstruction set VLSI computer”. In:Proceedings of the 8th annual symposium on Computer Architecture. IEEE Computer Society Press. 1981, pp. 443– 457

    1981

  10. [18]

    PaX: Twelve Years of Securing Linux

    PaX Team. PaX: Twelve Years of Securing Linux. 2012. url: https: //pax.grsecurity.net/docs/PaXTeam-LATINOWARE12-PaX-linux- security.pdf

    2012

  11. [19]

    Nvidia, Western Digital at Chips’ Frontier

    Tiernan Ray. Nvidia, Western Digital at Chips’ Frontier. 2018. url: https://www.barrons.com/articles/nvidia-western-digital- at-chips-frontier-1516640945

    2018

  12. [20]

    Writing IA32 alphanumeric shellcodes

    RIX. “Writing IA32 alphanumeric shellcodes”. In:Phrack 57 (2001). url: http://phrack.org/issues/57/15.html

    2001

  13. [21]

    The SPARC Architecture Manual, Version

    SPARC International, Inc. The SPARC Architecture Manual, Version

  14. [22]

    url: https://www.gaisler.com/doc/sparcv8.pdf

    1991. url: https://www.gaisler.com/doc/sparcv8.pdf

    1991

  15. [23]

    2017.url: https://content.riscv.org/wp-content/uploads/2017/05/ riscv-spec-v2.2.pdf

    Andrew Waterman and Krste Asanović.The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 2.2. 2017.url: https://content.riscv.org/wp-content/uploads/2017/05/ riscv-spec-v2.2.pdf

    2017

  16. [24]

    Filter-resistantCodeInjectiononARM

    YvesYounanetal.“Filter-resistantCodeInjectiononARM”.In: Jour- nal in Computer Virology7.3 (2011), pp. 173–188.issn: 1772-9890. url: http://www.fort-knox.org/files/virology.pdf. 22 A Hello World Shellcodes We provide ready-to-use demo shellcodes, written respectively in#RV64IC,...

    2011

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.