Just wondering, how long did it take you to find the vulnerability and write the exploit? I am venturing for the first time into exploit development and I'd like to know how long it takes for a professional (or in this case, two professionals) in this sector to find a vulnerability and write a working exploit for it. Also, fantastic content! Edit: Mainly for comparasion purposes, I don't expect me to find a vulnerability and write an exploit for it in a couple of hours (maybe in a couple of months, if the stars align nicely 😂)
The whole process was done in 3 stages: 1. Finding the vulnerability: that was relatively fast, we played with the binary a bit, did some recon but we got lucky with our "fuzzer". It probably took us less than 2 days of work. 2. Understand why it was crashing: we had a huge payload that was crashing a service. But it took some time to learn where it was crashing, why and to create an isolated PoC. We had to learn about DNS internals through the RFC, reverse engineer all the code, and link the concepts to the code. This took us a least 3 days. 3. Writing the exploit: this took the "3 long days and nights" mentioned in the video, plus an additional two days to clean it up and make it reliable. In all honesty we don't remember very well, since it was 4 years ago. But we estimate the whole process to have taken around 2 weeks or more. Since then we have gained quite a bit of experience; it's hard to say how long it would take us now, but a fair estimate would be 20 to 50% less time. This is not a certainty - there's always an element of luck involved in many of the stages, which might add or remove effort to the project. For example, if we had the "luck" to have good memory addresses in the stack, we could probably have written the exploit in one or two days. If we were unlucky with our "fuzzer" we could have easily spent 5 / 10 / 15 / 20 days reversing other binaries until we looked at conn-indicator and found the vulnerability statically.
@@FlashbackTeam Thank you for the kind insight into the process! I really like how exploit development requires a lot of research, I guess there is always something new to learn from it. So it's a process for which the time to go from vulnerability to an actual exploit may vary in length: it can be a one week journey or a much longer project if someone is rather unfortunate with the fuzzing, it is dealing with packed or virtualized binaries and so on. Once again, thank you for the kind feedback. This will help me a lot since I want to make a career out of exploit development and vulnerability research. ❤
Couldn't follow the code because my brain is upside down, but managed to follow what was going on generally. It's sad that people simply can't be bothered to implement proper security on devices connected to the Internet. It's mind-blowing really.
This is loaded with enough information that I could probably follow along but I think I’m gonna go spend some time learning about registers and stacks so it’s a bit easier to follow.
tplink could make it just a simple /bin/sh script that executes dig or nslookup and blinks an LED and that would be much easier and probably without exploits until dig and nslookup are ok, but they decided to do this stuff and probably did not have enough time to clean up this mess. Thanks, tplink, appreciate that!
You are absolutely correct. But we needed to simplify the ASLR concept as much as possible. Let's put it this way, we're both correct, you're just more precise :D
The Linux distro is personal preference in this case. We like to use Debian and Ubuntu. But sometimes we need to use Windows to run some hardware tools that might run only on Windows, keep that in mind.
im sorry but why the heck i cant lie some break on my tp-link wr940. I setup the gdbserver, place a break point in firmware check func. After hit continue, and use the upload firmware function to trigger the breakpoint. But damn, no break, the process is exit. Maybe some kind of protection ?
Hey Pedro …I am a “newbie “…what do you call this” stuff”..lol….I would like to get into this for fun ….lol….how do I go about it ???lol…..any recommendation into any free “interactive learning” websites would be appreciated lol
Binary search would not have helped here. It requires a constant feedback loop that we don't have. We have to spam all ports in all IPs in the list, so we just blast them all until we receive our shell.
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
Just wondering, how long did it take you to find the vulnerability and write the exploit? I am venturing for the first time into exploit development and I'd like to know how long it takes for a professional (or in this case, two professionals) in this sector to find a vulnerability and write a working exploit for it.
Also, fantastic content!
Edit: Mainly for comparasion purposes, I don't expect me to find a vulnerability and write an exploit for it in a couple of hours (maybe in a couple of months, if the stars align nicely 😂)
The whole process was done in 3 stages:
1. Finding the vulnerability: that was relatively fast, we played with the binary a bit, did some recon but we got lucky with our "fuzzer". It probably took us less than 2 days of work.
2. Understand why it was crashing: we had a huge payload that was crashing a service. But it took some time to learn where it was crashing, why and to create an isolated PoC. We had to learn about DNS internals through the RFC, reverse engineer all the code, and link the concepts to the code. This took us a least 3 days.
3. Writing the exploit: this took the "3 long days and nights" mentioned in the video, plus an additional two days to clean it up and make it reliable.
In all honesty we don't remember very well, since it was 4 years ago. But we estimate the whole process to have taken around 2 weeks or more.
Since then we have gained quite a bit of experience; it's hard to say how long it would take us now, but a fair estimate would be 20 to 50% less time. This is not a certainty - there's always an element of luck involved in many of the stages, which might add or remove effort to the project.
For example, if we had the "luck" to have good memory addresses in the stack, we could probably have written the exploit in one or two days.
If we were unlucky with our "fuzzer" we could have easily spent 5 / 10 / 15 / 20 days reversing other binaries until we looked at conn-indicator and found the vulnerability statically.
@@FlashbackTeam Thank you for the kind insight into the process! I really like how exploit development requires a lot of research, I guess there is always something new to learn from it.
So it's a process for which the time to go from vulnerability to an actual exploit may vary in length: it can be a one week journey or a much longer project if someone is rather unfortunate with the fuzzing, it is dealing with packed or virtualized binaries and so on.
Once again, thank you for the kind feedback. This will help me a lot since I want to make a career out of exploit development and vulnerability research. ❤
This type of content is rare nowaday, thank you for sharing it here.
this is amazing content. Thank you so much for detailing the entire process.
F yeah, was waiting this for a long time ❤
Couldn't follow the code because my brain is upside down, but managed to follow what was going on generally. It's sad that people simply can't be bothered to implement proper security on devices connected to the Internet. It's mind-blowing really.
I saw part 1 a few months ago and then I see them on my favorite darknet diaries podcast literally nothing more epic
This is loaded with enough information that I could probably follow along but I think I’m gonna go spend some time learning about registers and stacks so it’s a bit easier to follow.
Thanks!
Thank you for your support 🙏
tplink could make it just a simple /bin/sh script that executes dig or nslookup and blinks an LED and that would be much easier and probably without exploits until dig and nslookup are ok, but they decided to do this stuff and probably did not have enough time to clean up this mess.
Thanks, tplink, appreciate that!
30:12 "Let's stop here, as urmum is amazing, but it's not a valid command." 🤣🤣🤣
Awesome, and awe :( 18:18 the cat didn't make it :( 😿
Well worth the wait.
Any chance you'd make a video on the serial port of the Nexus 6P? I read somewhere that the UART is actually inside the headphone jack!
kick ass video good sir.
Is the extra byte because of misaligned stack?? 9:27
Would you recomend the pickit 5 as an analysis tool set
[22:16] Binary itself doesn't use ASLR, just the PIE is disabled:)
You are absolutely correct. But we needed to simplify the ASLR concept as much as possible. Let's put it this way, we're both correct, you're just more precise :D
@@FlashbackTeam hehe well said! btw, just for the record (and to mark down that I'm not a d-bag) I think that the content you make is freaking cool!
Awesome content. But which OS you use for IoT hacking?
Thanks! We both use Linux.
@@FlashbackTeam thanks for reply. But i mean which Linux flavour. Is it specific for hardware or a journal distribution?
The Linux distro is personal preference in this case. We like to use Debian and Ubuntu. But sometimes we need to use Windows to run some hardware tools that might run only on Windows, keep that in mind.
"Hey!! I'm not noob" *clicks on the first video*
Love your videos!
im sorry but why the heck i cant lie some break on my tp-link wr940. I setup the gdbserver, place a break point in firmware check func. After hit continue, and use the upload firmware function to trigger the breakpoint. But damn, no break, the process is exit. Maybe some kind of protection ?
Szacuneczek 👍
Is it necessary to have JTAG in order to debug the DNS server with gdbserver? If so, how is it possible to create an exploit without debugging..
what is that 3 videos you made private in your playlist. Where can we find it?
Hey Pedro …I am a “newbie “…what do you call this” stuff”..lol….I would like to get into this for fun ….lol….how do I go about it ???lol…..any recommendation into any free “interactive learning” websites would be appreciated lol
We highly recommend you start your reverse engineering journey with beginners.re
Having said that, we will have some beginner courses up soon!
I would to pick yalls brain on how to pull the firmware off of a Nimble CS 1000. My ch341a is always bringing bad data
please make course web app test
Not a noob
38:00 binary search wouldve been faster here
Binary search would not have helped here. It requires a constant feedback loop that we don't have. We have to spam all ports in all IPs in the list, so we just blast them all until we receive our shell.
@@FlashbackTeam I stand corrected thanks
Please make more vd and make server Discord
Hi! We have a private Discord server, but that's only for people who have attended our training course :-)
Terrible coding style
I think you're missing the whole point of the video here.
Thanks!
Thank you very much for your support!
Thanks!
Thank you very much for your support!