Back to Home11/14/2025, 11:39:36 PM

No Leak, No Problem – Bypassing ASLR with a ROP Chain to Gain RCE

todsacerdoti

113 points

11 comments

Mood

thoughtful

Sentiment

positive

Discussion Activity

Moderate engagement

First comment

Peak period

Day 1

Avg / period

Comment distribution8 data points

Based on 8 loaded comments

Key moments

01Story posted
11/14/2025, 11:39:36 PM
4d ago
Step 01
02First comment
11/15/2025, 2:55:44 AM
3h after posting
Step 02
03Peak activity
8 comments in Day 1
Hottest window of the conversation
Step 03
04Latest activity
11/15/2025, 4:24:53 PM
3d ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (11 comments)

Showing 8 comments of 11

nneonneo

4d ago

2 replies

If I read this correctly, they’re “bypassing ASLR” because the binary isn’t PIE, so it’s loaded at a static address.

I would not consider this actually bypassing ASLR, because ASLR is already turned off for a critically important block of code. Practically any large-enough binary has gadgets that can be useful for ROP exploitation, even if chaining them together is somewhat painful. For ASLR to be a reasonably effective mitigation, every memory region needs to be randomized.

OneLessThing

4d ago

1 reply

Yeah :/ that’s how I read it too. It would make more sense if they motivated the reason to find libc because like you said you could likely just use the non aslr gadgets exclusively. I think the author tried to use non aslr gadgets but had issues so went to the approach of using the GOT libc address and called that approach “bypassing ASLR”.

It’s a matter of opinion I guess. In the early days of ASLR it was common to look for modules that were not position independent for your ROP chain and that process was probably called bypassing aslr. These days we’d probably just call that not being protected by aslr.

aziz_k

3d ago

you can't just use gadgets from the binary and pop a shell, if it was possible the author would have done it, they needed to ret2libc.

LegionMammal978

4d ago

This is a bit interesting in how it doesn't require further interactivity with the attacker once the libc address has been obtained, unlike most basic ROP examples, which I've rarely seen require anything fancier than return-to-main. The more the chain does in a single pass, the more it might need gadgets smarter than "set register to immediate and return".

alchemio

3d ago

The most shocking part is the absence of stack canaries. I know there are issues with them on microcontrollers, but still I would assume they’re enabled by default by the compiler.

OneLessThing

4d ago

Good job. It’s early 2000s level stuff but it’s still exciting when it’s happening on your desk. There are lots of options in this scenario outside of bypassing ASLR so I do find it odd to be the main feature of the title, but a fun read nonetheless.

It’s fun working on targets with a less established research history. And I love a soup to nuts writeup, Thanks.

BiraIgnacio

3d ago

"No Leak, No Problem - Bypassing Address Space Layout Randomization with a Return-Oriented Programming Chain to Gain Remote Code Execution"

Expanding it, perhaps to the benefit of others like me.

kingforaday

3d ago

You typically don't see ASLR enabled on these armhf embedded devices. I see the statement by the author, " quickly confirmed on the device that address space layout randomization (ASLR) was enabled...", but how was it quickly checked? What was the output of /proc/sys/kernel/randomize_va_space?

Also not familiar at all with the checksec program, but from my look at the documentation, you expect to see PIE enabled not DSO (which implies dynamic shared object).

3 more comments available on Hacker News

View full discussion on Hacker News

ID: 45933497Type: storyLast synced: 11/16/2025, 9:42:57 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Read Article View on HN