Getting up in another processes memory
Вставка
- Опубліковано 3 лис 2023
- In this video, we learn how we can read memory belonging to other processes by building a memory dumper from scratch.
One of the key components is the /proc file system: an interface that the kernel provides for introspecting processes. Combined with ptrace, a system call that allows attaching to and taking control of another process, we write a program to automate extracting information that would otherwise be completely hidden to us!
=[ 🔗 Links 🔗 ]=
j3s.sh/thought/recover-lost-t...
🗣 Discord: / discord
⭐️ Patreon: / lowleveljavascript
💻 Github Repo: github.com/lowbyteproductions...
Bro is single-handedly saving us form the clickbait, idiotic drama inducing, and worthless "programming creators" out there.
Thank you so much about making these kinds of videos, been watching a lot of your channel lately.
🙏
Hey I've been following your videos for a few weeks now and just wanted to say thank you for making this content. I think you are filling a very import void that its often overlooked or underrepresented in video form. I like you teaching style and makes everything very clear I can confidently say that this is making me a better programmer and just yesterday I was looking into using ptrace at work. Wish you the best of luck!
🙏
normally i got bored for watching video longer than 20 minutes, but this video is an exception. Learned something new :)
For getting functions from the C library in python, you can just call CDLL with an empty string and not need to worry about what the exact name the libc shared object has. This will boil down to calling dlopen with null which will give you a handle for searching all the the symbols imported by the python executable including the C library which it will obviously be linked with.
Huh today I learned. Thanks!
Mind-blowing for me. Now I am much closer to understanding how game cheats works! Thanks 😅
Definitely on the right path!
been diving into your videos a bunch this week. great content! thanks for posting
Fantastic video as always. I so much enjoy all of your videos especially parts about OS internals.
I would like to say thank you so so much, I enjoyed and learned a lot from your videos in recent weeks. great work.
One more thing that I want to share here is, I really like the way you make a video. With full screen of the code editor, the camera angle to your face, the pace and your calm & clear voice, everything is perfect.
🙏
Loving your content. I use it as a relaxing way to start my weekend days with my morning coffee! Especially loved the way you teach the python to c stuff, never thought about using Python like this!
Really enjoyed this! Super clear, casual and interesting
Very cool, more of these please! They're hard to find
Great video! I learned a lot.
Enjoying the videos and today I learned a bit more about how to use Python today, as a non-pythonist.
I have to routinely go to the proc folder and look for content there, on containers/pods inside Kubernetes/Openshift that have almost zero Linux tools. We assume that all the distros get at least a set of basic tools, but you'd be surprised how many of the commands are missing.
I've spent quite a bit of time in my career as sys programmer using /proc - it's been around for ages but I love the way all the files are text now - some versions of Unix used to store binary data. I've never known what to do with the 'mem' file so thanks for this detailed explanation. I've always used C and I've never used Python so it's great to get a tutorial on that as well! - it would have been a bit painful to do in C. Loving all your videos!
I didn't realise that they were binary at some point. I can imagine that would have made changes between kernel versions tricky because it could break userspace code relying on the characteristics of binary structures. Always bet on text!
@@LowByteProductionsLinux has always been text in /proc - the main thing I've used is /proc/pid/stat to get all the characteristics of a process. AIX, for example, has a binary format for the process info in /proc which just maps onto a struct. I do seem to remember /proc/pid/stat in Linux varying between kernel versions slightly ...
Just out of interest I implemented the dumper in C - obviously the ptrace calls are simpler in C but overall I like the look of Python
I imagine that's also how cheat-engine works it's a pretty interesting program I remember using it to change some variables in some offline games like getting infinite bullets i had no idea what I was doing, but it was magic. man good times
Pretty much! And I had very much the same experience.
I love your content so much ❤
Loved this.
First of all you are amazing. Thats all!
It’s very cool :)
Big thanks :)
Loved this video so much! Thanks.
Great video ❤
"macOS, with its BSD roots, doesn't have a proc filesystem" - google. Loved the vid, thanks!
Huh I could have sworn mac had procfs! Well live and learn. BSD definitely has it though.
I did not really understand why ptrace is used here. Just to be sure the programm stops running? Would it be possible to just use ptrace without the proc fs to read the data? Are the two void* args there for that purpose?
You can't read another processes memory unless you're tracing it. You can indeed read memory without the procfs, but this is a more efficient way of reading large chunks at a time.
@@LowByteProductionsHow were you able to read the mem file from the proc fs in terminal then? or is it also doing all the ptrace magic behind the scene that we are not aware of?
Also recently subscribed, love the detailed explanations and low level stuff! wish more yt channels were like this
thanks for this! never thought about just core dumping my browser when that happens, its obv
Right!
awesome
Hi, thanks for your video, I'd like to ask if ptrace is mandatory if I have the root permission?
By the way, it’s `man 5 proc`
Thank you, I absolutely flailed trying to summon that command!
Love the videos! Could someone please explain why you are able to cast c structs/types all to c_ulong? And also, what would happen if you didn't ptrace attach/detach? Is the advantage of ptrace here just that is pauses execution? Thanks! Sorry if it's a silly question
Well basically, the parameters are all able to be represented using the 64 bits of a long. The "enum" type in C is internally represented as an integer, (0, 1, 2, ... for each element in the enumeration), so it can be held easily in a long; the PID is also an integer, and will definitely fit within a long; and the address/data void* pointers are 64 bits (or as long as whatever your architecture is), so a long (which is also 64 bits on virtually all systems) is able to store these as well. In C you can 'upcast' any type to another type which is wide enough to store it, so there is technically no problem here. The only thing is that it's not perfectly portable, because a ulong is not necessarily guaranteed to be 64 bits, blah blah blah, but it works 99% of systems I think.
I don't really know much about ptrace, but I assume what you said is the main point: at 44:58 he mentions this idea that you don't want the active process to mess up the memory while you're still trying to dump it, which could prevent you from recovering that lost data.
@spaghettiking653 thanks so much, that actually makes so much sense! (I also love ur name haha)
@@Spaggei0hs Ah a fellow man of culture! I didn't notice your name first time round, love yours too :ppp anyway, glad that was of help.
When is the next video
20:50 - *Picture this: Hyphens (-) are literally not dashes (-).*
Incredible dedication to your craft 👏