Email or username:

Password:

Forgot your password?
Top-level
pancake :verified:

@j3s or just open proc/pid/mem with r2 and search the text. No need for coredumps or ptrace :3

7 comments
Netux

@pancake @j3s garbage collection is the enemy, catching and pausing with gdb may be faster than figuring out a good regex

pancake :verified:

@Netux @j3s i prefer sigstop. Much less intrussive than ptrace. And i would never use regex to search in raw memory, it's too slow. Also worth considering searching wide strings if text was cached by javascript

Netux

@pancake @j3s ashamed to admit I didn't even think of sigstop. So rare that I use signals beyond kill and int.
Regex of just matching text, not any magic. Still a regex.

pancake :verified:

@Netux @j3s i use ^Z a lot, the problem with regexes is that they are suposed to run on a limited space in memory. this is, if you use strings is fine, but when searching in memory, the regex expression can expand to read 4GB of memory to find a matching token, and this is not really optimal. Most forensic tools supporting regexes restrict the contents to search in or add limits to the regex engine

Netux

@pancake @j3s suppose restricting it to the data segment wouldn't be too hard. Not enough experience on the exploit side of things to know if proc makes it easy to do. Cat through awk maybe? Cat is unbuffered, right? I know you can set grep to be.

pancake :verified:

@Netux @j3s the only way to use procpidmen is via mmap so cat wont work. And yes its possible and desirable to define boundaries when searching on raw memory. Actually the maps file describes the heap, etc so you can use e search.in=io.maps.rw and that would reduce the search to the writable maps. Which is where the user data is stored and avoid scanning the code ir readonly segments

✨jes✨

@pancake good callout :3 i prefer the core dump just in case i have to futz around with the query, but nabbing it straight from memory is very dope too

Go Up