Yes, the Lena tutorials are the industry standard, if you can refer to the cracking scene as an industry. As far as I remember they are targeted towards blackhat crackers but the information is still valuable even for aspiring security researchers or whitehats.
I recently started a YouTube series on hacking. With a main focus on reverse engineering and memory corruption. I'm currently on episode 0x5 and I currently release them biweekly.
I understand the paranoia, but quite frankly "unknown provenance" is just FUD. Countless others, including me, have used them with no problems. Due to the demographic of their intended audience, I doubt any maliciousness could remain undetected and unannounced for long --- trying to hide something from a community of reverse-engineers tends to be rather difficult. ;-)
Fair enough, it just hit too many of my "this seems sketchy" twitches. Would be nice if they had some mpeg 4 or whatever as well. I could break out ffmpeg but can't remember how to convert so I just don't bother. Other things to do in either case so no big loss.
Having a goal helps too. I tried and failed to learn x86 assembly a number of times in 2015 and then decided to focus more on modem firmware analysis instead. Sure, it's a bit of a cop-out (I can get a lot further without looking at any assembly code) but I'm slowly coming back around to reverse engineering the long way around.
One way to get familiar with assembly is to get a development board that can run bare metal code. You could even start with something that isn't x86, but is assembly. Once you complete a driver, game, or some other project in assembly, learning another assembly becomes considerably easier.
There is a mindset involved. You can get it on a 6502, if you want to, but you have to have it in order to make any real sense of assembly language, IMHO.
I have my struggles with this too, but I find it always interesting and fascinating. Goes back to the days of cracking games and opening up licenses on simpler, smaller computers.
I also believe a number of us should maintain and share these skills. It's important for a lot of basic reasons, and those don't have to be piracy, or nefarious malware reasons. It may be as simple and benign as using something we own to do something we want it to do as opposed to what it was originally intended to do.
I've never quite been able to shake the feeling of being born in the wrong era. I didn't start learning programming til I was 12, and I jumped straight into higher level languages. While I'm thankful for StackOverflow, I've got a bookshelf full of things like Peter Norton's Guide to Assembly just waiting for a spare week or two.
I sometimes feel I missed things too. For me, it's a better era alignment in that I was writing low level code on the simpler machines. But, I did step away for quite a while doing manufacturing, CAD, and a lot of related things.
All of which were very interesting, but my real love is programming and circuits. So, now I'm back, making progress, loving it, but also feeling a bit out of place.
It's what you do with what you have and being open to always learning. Reading Masters of Doom and Making of Prince of Persia, I was around (if a few years younger) during this time but I didn't have the drive these people did until much later. If you have the drive, then you can do great things, regardless of the era.
Absolutely. Besides knowing Asm, the other thing I've noticed is that debugging/general analytical problem-solving skills --- being able to grok the code and understand its operation in general, without having written it --- is highly correlated with RE skills. Of those I've worked with, those who are highly skilled at debugging tend to have RE experience; and likewise those who can easily do RE, even if it's something like analysing a protocol/interface and writing a specification, also tend to be very effective debuggers.
As others have said it's mostly the desire to learn. A lot of the brightest reverse engineering I have met started off hacking video games. They started with a desire to either understand the game or create cheats. From there they dug into the code.
Reverse engineering has a very romantic view from the outside. In actuality a lot of it is learning esoteric topics and boring concepts to be able to apply it to a single task. It takes a certain mindset to stick with it.
The main pre-requisite is being able to read and understand assembly language. From there it's operating system fundamentals, memory layout, compilers, basic understanding C & C++ and Python is popular in the RE community.
The RE sub-reddit has a good introduction for beginners.
If you prefer video tutorials to a book, be sure to check out the Lena151 tutorials: https://tuts4you.com/download.php?list.17
If you want to practice your reverse engineering skills in a legal manner, check out crackmes.de: http://crackmes.de/
tuts4you also has a nice crackme/unpackme section.
Yes, the Lena tutorials are the industry standard, if you can refer to the cracking scene as an industry. As far as I remember they are targeted towards blackhat crackers but the information is still valuable even for aspiring security researchers or whitehats.
What do you think about this? http://reversewithme.blogspot.sk/2012/10/why-lena151-tutoria...
Dude thank you these are incredible! Especially since I know I'm more of a visual learner, these vids look primo
I recently started a YouTube series on hacking. With a main focus on reverse engineering and memory corruption. I'm currently on episode 0x5 and I currently release them biweekly.
https://www.youtube.com/playlist?list=PLhixgUqwRTjxglIswKp9m...
I also record myself playing CTFs and I just created a video walkthrough of the pwnable 200 challenge from the 32c3 CTF: https://www.youtube.com/watch?v=wLsckMfScOg
Maybe it helps somebody.
High quality. Thank you!
Good stuff. Consider posting in https://www.reddit.com/r/ReverseEngineering/
Hmm, flash files relating to reverse engineering?
I'd love to watch it but yeah not touching things like that of unknown provenance.
I understand the paranoia, but quite frankly "unknown provenance" is just FUD. Countless others, including me, have used them with no problems. Due to the demographic of their intended audience, I doubt any maliciousness could remain undetected and unannounced for long --- trying to hide something from a community of reverse-engineers tends to be rather difficult. ;-)
Fair enough, it just hit too many of my "this seems sketchy" twitches. Would be nice if they had some mpeg 4 or whatever as well. I could break out ffmpeg but can't remember how to convert so I just don't bother. Other things to do in either case so no big loss.
You don't need to install the Flash plugin in your browser. You can use a standalone reader that handles SFW files(like GOM Player).
I highly recommend downloading your router/modem firmware and having a look at it. Even running `strings` against it should be quite interesting.
If you're interested in unpacking a firmware then have a look at `binwalk` [1]. It might even work against your Blu-Ray player!
1: http://binwalk.org
Another way to learn is watch Charlie Miller reversing hardware presentations https://youtu.be/_9ErnoLVxCA
For example he notices a pattern, so assumes it must be a return after a function. From there he can reverse their proprietary battery controller
What are the prerequisites? Knowledge of computer architecture A to almost Z?
Just a desire to learn. I gave this a quick glance, and it's reasonably complete in terms of foundation material.
It's not going to be difficult for people lacking some things to go and look them up in context.
The most important skill here is knowing what you don't know and the secondary skill of paying close attention to what you see happening.
One might want to explore electronics enough to use a scope, logic analyzer, etc...
This is a pretty great book, and I look forward to exploring it.
Having a goal helps too. I tried and failed to learn x86 assembly a number of times in 2015 and then decided to focus more on modem firmware analysis instead. Sure, it's a bit of a cop-out (I can get a lot further without looking at any assembly code) but I'm slowly coming back around to reverse engineering the long way around.
Oh it does indeed!
Well said, and agreed completely.
One way to get familiar with assembly is to get a development board that can run bare metal code. You could even start with something that isn't x86, but is assembly. Once you complete a driver, game, or some other project in assembly, learning another assembly becomes considerably easier.
There is a mindset involved. You can get it on a 6502, if you want to, but you have to have it in order to make any real sense of assembly language, IMHO.
I have my struggles with this too, but I find it always interesting and fascinating. Goes back to the days of cracking games and opening up licenses on simpler, smaller computers.
I also believe a number of us should maintain and share these skills. It's important for a lot of basic reasons, and those don't have to be piracy, or nefarious malware reasons. It may be as simple and benign as using something we own to do something we want it to do as opposed to what it was originally intended to do.
I've never quite been able to shake the feeling of being born in the wrong era. I didn't start learning programming til I was 12, and I jumped straight into higher level languages. While I'm thankful for StackOverflow, I've got a bookshelf full of things like Peter Norton's Guide to Assembly just waiting for a spare week or two.
I sometimes feel I missed things too. For me, it's a better era alignment in that I was writing low level code on the simpler machines. But, I did step away for quite a while doing manufacturing, CAD, and a lot of related things.
All of which were very interesting, but my real love is programming and circuits. So, now I'm back, making progress, loving it, but also feeling a bit out of place.
We are not alone, of that I am sure.
It's what you do with what you have and being open to always learning. Reading Masters of Doom and Making of Prince of Persia, I was around (if a few years younger) during this time but I didn't have the drive these people did until much later. If you have the drive, then you can do great things, regardless of the era.
There is a mindset involved
Absolutely. Besides knowing Asm, the other thing I've noticed is that debugging/general analytical problem-solving skills --- being able to grok the code and understand its operation in general, without having written it --- is highly correlated with RE skills. Of those I've worked with, those who are highly skilled at debugging tend to have RE experience; and likewise those who can easily do RE, even if it's something like analysing a protocol/interface and writing a specification, also tend to be very effective debuggers.
As others have said it's mostly the desire to learn. A lot of the brightest reverse engineering I have met started off hacking video games. They started with a desire to either understand the game or create cheats. From there they dug into the code.
Reverse engineering has a very romantic view from the outside. In actuality a lot of it is learning esoteric topics and boring concepts to be able to apply it to a single task. It takes a certain mindset to stick with it.
The main pre-requisite is being able to read and understand assembly language. From there it's operating system fundamentals, memory layout, compilers, basic understanding C & C++ and Python is popular in the RE community.
The RE sub-reddit has a good introduction for beginners.
https://www.reddit.com/r/ReverseEngineering/comments/hg0fx/a...
I like the French Cafe parable by Andrew Tridgell of Samba on the topic https://www.samba.org/ftp/tridge/misc/french_cafe.txt
Isn't that more specific to protocol reversing?
Wow! This is a massive book! Here's my New Year's Resolution staring me in the face.
There's a lite version available on the same page.
I began reading this book yesterday. So far it's a good introduction to analysing and manipulating ASM.
You'll need a windows system though. I found that the GCC examples didn't match up with what I was seeing on my Debian VM.
Because of different compiler versions, maybe?
Turns out I was compiling to 64bit which changes the ASM.
I compiled to 32bit and then ran IDA-free version using WINE on OSX (Hopper's output was too different).
Output is now identical.