From bas at collarchoke.org Sat Aug 1 19:52:48 2015 From: bas at collarchoke.org (Bas Alberts) Date: Sat, 01 Aug 2015 19:52:48 -0400 Subject: [Dailydave] The old speak: Wassenaar, Google, and why Spender is right Message-ID: This will be a long and ranty one as well as the first DD post I've made in a non-Immunity capacity (I think). So anyone that knows me on any personal level knows that I'm a non disclosure kind of guy. Now I could get into the why and how, but what it really boils down to is that I subscribe to a fairly peculiar belief system in which freedom and security are, generally speaking, mutually exclusive. I think that in an effort to "secure" the internet, most so called privacy advocates and full disclosure zealots are actually contributing to a power structure that promotes totalitarian levels of control. A secure internet is, by definition, a controlled internet. If you're talking about software security, anyways. I've made that point in various forms before on this mailing list, but it has become ever so relevant in recent times due to the proposed US Wassenaar implementation. I thought it was interesting, if not telling, that the USG aligned themselves with what is essentially a full disclosure policy. The proverbial get out of fail free card for the 1st round of proposed Wassenaar export control legislation was essentially "as long as you tell all you are okay". As long as you tell all you are in the green. How on earth does that sentiment align with any privacy advocacy? It is absurd. Yet we see many a self confessed full disclosure zealot and privacy advocate froth with an almost sadistic glee at the idea of a government enforced full disclosure. Finally all those scumbag xdevs are forced to show their cards. Finally it will all be out in the open. Because that is what privacy is about right? Forcing things into the open through Government control? When I see someone like Chris Evans essentially cheerleading Full Disclosure as law on his tweeter it fundamentally rubs me, as an American (HA!), the wrong way. Then you have people like Chris Soghoian, who's entire pro-Wassenaar argument was based on non-US companies. Lest we forget that HackingTeam was actually fully Wassenaar compliant under even the strictest interpretations. Which demonstrates exactly why and how it is a moot endeavor. I also think it's interesting how the HackingTeam thing was performed in the blackhat tradition of dumping mailspools. What is WikiLeaks if not a crowdsourced big-data analytic version of ~el8 at this point? I think you took a wrong turn somewhere team privacy. But that's just me, I suppose. Anyways, both sides of the disclosure fence suffer from one fatal flaw. A flaw that Brad Spengler AKA Spender has been incessantly pointing out for years and it's that bugs don't matter. Bugs are irrelevant. Yet our industry is fatally focused on what is essentially vulnerability masturbation. I keep up with the Google Project Zero blog because I think it's hilarious to see them fawn over bugs like they're actually hacking with them. "This is the perfect bug", "This exploit is beautiful", and many other such paraphrases are rife in a lot of the Project Zero publications. I suppose that's what happens when you spend a couple of million dollars on tricking out a team of vulndev mercenaries, most of which were playing on the other side of the fence for many years before stock options and bonus plans took precedence over actually hacking (or facilitating such). I'm sure there's some true believers at Google. Ben Hawkes, Chris Evans, Tavis Ormandy. They are ride or die full disclosure zealots (AFAIK) and I may not agree with them in principle, but I do appreciate and even respect the strength of their conviction. Having said that, if you gave me a billion dollars today, what percentage of the Google security team could I employ tomorrow? It's an interesting question I think. From an adversarial perspective that is. Say e.g. the NSA or whoever actually cared about someone fixing "hundreds!" of bugs in desktop software and the real Internet wasn't a facsimile of an early 90ies LAN party. Say that was the case. If "they" got _real_ budget to buy out all the "top researchers" in the industry, do you honestly think it wouldn't cripple Google's effort overnight? And that's essentially the crux of the problem. You can't fight religious wars with mercenaries. You need martyrs. When your team is for sale, it's very hard to align yourself with any sort of ethical, moral or even altruistic high ground. And hey, again, not judging. It's a job for most. Myself included. I'm 35 and I could give less of a fuck about whether or not my homies from whatever Scandinavian country are keeping down their roots this week. Which, btw, I'm sure they are. Anyhoo, back to the actual ranting. Ben Hawkes stated that "attack research in the public domain" is the way forward for security. The problem with that is that the majority of his team got skilled in the non-public domain. Attack research doesn't get good in the public domain, it gets good because it is used to, you know, attack. It has to jump through hoops and quirks and work over sat hops and against thousands of targets and do all sorts of weird things that would never come up in a lab environment. This whole modern game of public exploit vs mitigation is a circle jerk based on a seed that came from the dark, and people forget that. A lot of people currently making their bones killing bugs for Google (or whoever) got good because they spent time on teams doing actual attack research for actual attacks. Hell, some of them are near and dear friends of mine. I suppose it's the elephant in the room that noone wants to talk about. You got your ex-vupen, ex-teso, ex-adm, ex ... well you get the idea. Anyhoo, back to why we're all wrong and Spender is right. At the end of the day my team, Google's team, and lots of people's teams are rooted in a culture of vulnerability masturbation. We fawn over "beautiful" bugs and OMGWOW primitives and can wax endlessly about how we understand such and such allocator to the point where you could play a game of goddamn minecraft with nothing but a heap visualizer and your allocation/deallocation primitives. 30 page dissertations on over-indexing an array and hell we'll even hold court about it at whatevercon for 60 minutes ... autographs at the bar. And it's all bullshit. If you care about security that is. "But to stop exploitation you have to understand it!". Sure. But here's an inconvenient truth. You are not going to stop exploitation. Ever. You might stop my exploitation. You might stop my entire generation's exploitation. But somewhere the dark is seeding away methodologies you don't know about, and will never know about. Because somewhere hackers are hacking, and they've got shit to do. None of which includes telling you about it at blackhat or anywhere else. That is empirically the truth. So if you truly, deeply, honestly care about security. Step away from exploit development. All you're doing is ducking punches that you knew were coming. It is moot. It is not going to stop anyone from getting into anything, it's just closing off a singular route. One of many that ultimately falls through to the proverbial 5 dollar wrench; pending motivation, time, and available resources. If someone _REALLY_ wants your shit, they can take a bat to your head and take it. End of exploit. I say this as someone who's made a career out of exploit development. It's been my life for 20 years. But I make no mistake about it being a labor of love. A function of an OCD-like addiction to solving puzzles and even though I spend most of my days filling out spreadsheets these days, I still love me a good 30 page dissertation on world shattering font bugs ... even though, and trust me if I tell you most of team Google damn well knows this, many people have sat on the exact same dissertation for many years. But if you care about systemic security. The kind where you don't give two flying fucks if Bob's desktop gets clientsided or Jane's Android doesn't know how big an mpeg4 frame oughta be, then you will stop circle jerking over individual vulnerabilities and listen to what Spender has been saying for years. Which is: you don't chase and fix vulnerabilities, you design a system around fundamentally stopping routes of impact. For spender it is eradicating entire bug classes in his grsecurity project. For network engineers it is understanding each and every exfiltration path on your network and segmenting accordingly. Containment is the name of the game. Not prevention. The compromise is inevitable and the routes are legion. It is going to happen. Now as far as a way forward for YOUR security ... well I play on team offense. I'm allowed to fawn over vulnerabilities and I think xdev and art often intersect. Pretty polly payload, bro. But if you're supposedly my adversary (i.e. on team defense) and yet you're sitting right alongside me going "oooh" and "aaah" at whichever software vulnerability then you're probably in the wrong place, or ... I suppose ... maybe just in the wrong time. Love, Bas -- PGP Pub Key: https://www.collarchoke.org/0xBED727DF.asc Fingerprint: 5C1A 3641 8542 7DFA F871 441A 03B9 A274 BED7 27DF From lcamtuf at coredump.cx Sun Aug 2 00:14:24 2015 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Sat, 1 Aug 2015 21:14:24 -0700 Subject: [Dailydave] The old speak: Wassenaar, Google, and why Spender is right In-Reply-To: References: Message-ID: > Anyways, both sides of the disclosure fence suffer from one fatal > flaw. A flaw that Brad Spengler AKA Spender has been incessantly > pointing out for years and it's that bugs don't matter. Bugs are > irrelevant. Yet our industry is fatally focused on what is essentially > vulnerability masturbation. To be very frank... I think you're a bit guilty of the same oversimplification that you attribute to the 0-day crowds :-) Containment and detection matters. So does proper system design. And yup, every enterprise should plan for getting owned, instead of assuming that the AV software on their workstations will be able to stop bad guys in their tracks. But squashing bugs matters, too - not on an individual scale, but because all other principles aren't worth much if any attacker is likely to have a cache of trivial 0-days for *every* single layer of defense that you have in place. I'm sure that neither you nor Brad are running 15-year old copies of Apache and OpenSSH, or browsing the web with Netscape Navigator, and then putting all your faith in containment frameworks. Now, that aside... I don't really follow parts of your argument against vulnerability disclosure as a concept - or more specifically, I don't see the inherent connection to privacy worries, to government oppression, to black hat mercenaries, or to flashy conference showmanship. That said, I think it's hard to have a perfectly rational discussion about such deeply-held beliefs, and I recognize that my own views are hopelessly subjective =) > Having said that, if you gave me a billion dollars today, what > percentage of the Google security team could I employ tomorrow? Here, I'd just say what I mentioned to Dave in an earlier thread: people have strong beliefs about P0, and I think it's fine. But from what I recall, P0 amounts to somewhere under 5% of Google's security & privacy headcount - so projecting these beliefs onto the entire security org just doesn't seem right. /mz From lcamtuf at coredump.cx Tue Aug 4 11:12:41 2015 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Tue, 4 Aug 2015 08:12:41 -0700 Subject: [Dailydave] The old speak: Wassenaar, Google, and why Spender is right In-Reply-To: <55C0B4AF.31516.14DDBD3A@pageexec.freemail.hu> References: <55C0B4AF.31516.14DDBD3A@pageexec.freemail.hu> Message-ID: > and how does finding/fixing bugs change that? are you saying that p0 > efforts resulted (or have a chance to result) in a *complete* extermination > of security bugs that affect a *single* layer at least? either that or > your bug squashing doesn't matter (for security). I am fairly confident that many core components that we depend on have gotten a lot harder to compromise over the years; we are obviously not at a point where there are no bugs left (and we're certainly not at a point where optimal design practices or mitigation frameworks are bulletproof, either), but at least subjectively, I feel that at any given time, far fewer people would be able to compromise my web server than in the 90s, and far fewer are likely to have a 0-day exploit for my browser, compared to 2000s. Some of this comes down to mitigations, sandboxing, and better design practices - although their adoption by non-security engineers is driven largely by the cold and hard evidence of failures. And in my view, a lot of it also comes down just to relentless fuzzing and manual code audits. Now, of course, it's hard to truly quantify such opinions, and if you think otherwise, I think it's quite fine to disagree :-) >> I'm sure that neither you nor Brad are running 15-year old copies of >> Apache and OpenSSH, or browsing the web with Netscape Navigator, and >> then putting all your faith in containment frameworks. > > we don't run new software because of the security bugs fixed in them > but because that's how the whole stack evolves Interesting; so the knowledge of an RCE in OpenSSH would not factor into your decision to stay on a particular version? That sounds like a bold move. /mz From lcamtuf at coredump.cx Tue Aug 4 11:42:10 2015 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Tue, 4 Aug 2015 08:42:10 -0700 Subject: [Dailydave] The old speak: Wassenaar, Google, and why Spender is right In-Reply-To: References: <55C0B4AF.31516.14DDBD3A@pageexec.freemail.hu> Message-ID: > Now, of course, it's hard to truly quantify such opinions, and if you > think otherwise, I think it's quite fine to disagree :-) To be perfectly clear, I actually strongly agree that indiviual bugs don't deserve PR releases, media packets, and flashy conference presentations. All that is just a product of human nature and a couple of twisted incentives. At the same time, I don't subscribe to the absolutist view that vulnerabilities don't matter, chiefly because I see ample evidence of such findings making developers more interested in security and improving their code - an because they keep us honest when we invent new ways to make software more secure. On balance, I do think that systemic improvements (design practices, sandboxing, mitigations) are more important where feasible, but I see a strong link between the two facets of security research. I'm always surprised when people speak in absolutes - be it when Bes or you get dismissive or vulns and vuln disclosure, or when researchers make a big deal out of individual findings and see themselves as kings of the world. /mz From darkpassenger at unseen.is Mon Aug 10 12:09:26 2015 From: darkpassenger at unseen.is (Darkpassenger) Date: Mon, 10 Aug 2015 09:09:26 -0700 Subject: [Dailydave] COMSEC Biopsy Message-ID: Brothers, in a medium scale investigation project to understand failure of secret communication of some NGO i am tasked with a smaller job , reversing and biopsy a java kit , which i cannot be more far away . help me . file is attached . here are the questions we have for the case which i believe suit this java component as well . i am told due to this failure a brigade of freedom fighters got killed while fate of some still unknown . 1. what websites are using exact or very similar to this code ? we expect the languages much be Turk , Arabic and perhaps Farsi or English 2. the code seems obfuscated . deonfuscate it in a way civilian analysis tools can understand it 3. are evidences available to support public code from te internet has been used in this code ? 4. what types of crypto has been used ? 5. is this kit able to carry exploits into the victim's machine while working ? 6 are there personal info inside this code resulting identification whole or part of its developer team ? 7. what are the IP addresses the kit is trying to connect to ? where are they located ? what are they background ? 8. in your opinion as a skilled java developer is this kit result of team work ? 9. how did they obtain the digital certificate and is this connect the kit to other elements in the big picture ? 10.is this kit try to spy on the host computer in any way ? 11. is this kit cross-platform ? 12. does the kit contains any java exploit or smart trick to bypass the regular average sandbox? 13. how would one attack this kit in wild and learn about the parties who are using it over the internet ? each question is essential to a part of this investigation that eventually help protect human rights in hostile environments all the bests Regards link : https://anonfiles.com/file/c4f69d6825292a5da1638319b217a4fa From dave at immunityinc.com Wed Aug 12 15:39:18 2015 From: dave at immunityinc.com (Dave Aitel) Date: Wed, 12 Aug 2015 15:39:18 -0400 Subject: [Dailydave] Exciting Things to Work On! Message-ID: <55CBA0E6.6050303@immunityinc.com> Lately both Charlie and Runa have posted to Twitter asking for some ideas of similar things to hack, other than cars and expensive Wifi-based lead-throwing equipment. I wanted to crowdsource some junkhacking ideas. The obvious tenets are that it must be something worthy of a talk and CNN interview, but be on something with no security design whatsoever - and especially not one hard enough to stand five minutes of attention from an ex-NSA hacker. For example,lots of companies are putting mesh networks into buildings to provide high speed internet to customers. You could, after a few minutes with a easy-to-pick lock, get into the room where the microwave terminus is, assuming you don't get boiled, and connect into that network to sniff, spoof, mess with routing, and otherwise fuddle around with the mesh network. Or just imagine the "fun" of messing with FireChat in Iraq! And if you want to stick with "Internet of Things" you could hit up the exciting world of networked airport security equipment! Yes! That's right, not only are basic airport security measures bypassable by putting things on certain places on your body, but they are networked computers as well! One quick plug into any of them can do lots of interesting things. IMAGINE THE DEMO ON STAGES AROUND THE WORLD, THE PRESS, THE "FAME"! Look, a lot of times the rubber pad isn't even under the metal detector, because nobody ever explained to the TSA that its whole point is to raise the people above the bottom of the detection field. So imagine how great the security is on the network traffic and various physical ports on those things. Trains. We don't have any in the United States. You might have to go to Shanghai to find one with enough networking equipment to hack. WHAT IF YOU CHANGED THE SPEED TO THE SAME AS AN AMTRACK? Patriotic, or irresponsible? Let's let Wired decide? :) -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: charlie.JPG Type: image/jpeg Size: 36206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: runa.JPG Type: image/jpeg Size: 41894 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: metal.JPG Type: image/jpeg Size: 167635 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From arrigo at alchemistowl.org Wed Aug 12 15:55:05 2015 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 12 Aug 2015 21:55:05 +0200 Subject: [Dailydave] Exciting Things to Work On! In-Reply-To: <55CBA0E6.6050303@immunityinc.com> References: <55CBA0E6.6050303@immunityinc.com> Message-ID: <1D0EBAB5-C98F-4F81-8DC2-0680158CF04C@alchemistowl.org> On 12 Aug 2015, at 21:39, Dave Aitel wrote: > > Trains. We don't have any in the United States. You might have to go to Shanghai to find one with enough networking equipment to hack. WHAT IF YOU CHANGED THE SPEED TO THE SAME AS AN AMTRACK? Patriotic, or irresponsible? Let's let Wired decide? Dave, please don't suggest that... in Europe, and in China because of the technology they "joint-ventured", we use a system called ERTMS2 (https://en.m.wikipedia.org/wiki/European_Rail_Traffic_Management_System). This now runs some of the most recent high-speed lines, I believe the first one activated was the Rome-Naples in Italy, and its security was allegedly tested amidst several issues due to the carrying of "weapons" (i.e. pentesting tools) on laptops. The whole system is based on GSM-R, the railway version of GSM at 900MHz (EU frequency for GSM). This might also be food for thought for some readers. Most readers on this list know where this will probably end and I don't think recommending stunt-hacking an ETR500 running at 300kph to Naples or a loaded TGV en route to Strasbourg is particularly smart. Adding to it China and their Alstom/Bombardier clones is hardly smarter, smilie or no smilie. Continue playing with your cars and guns in your mostly empty spaces. Perhaps consider playing with your planes over the Nevada Test Site? Cheers, Arrigo From dave at immunityinc.com Fri Aug 21 08:00:41 2015 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 21 Aug 2015 08:00:41 -0400 Subject: [Dailydave] Watching the watchers Message-ID: <55D712E9.4060801@immunityinc.com> https://vimeo.com/136868311 We posted this 7 minute video this morning with the results of a little tech project I did last week. You should watch it over coffee! -dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From dave at immunityinc.com Mon Aug 24 10:27:23 2015 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 24 Aug 2015 10:27:23 -0400 Subject: [Dailydave] The Stone Mind Message-ID: <55DB29CB.3030403@immunityinc.com> Lately in the exciting world of politics and regulation there's been a lot of focus on the nature of what an exploit is, which is a bit like watching collage freshman wrestle with a subtle zen-koan buried in one of J.D. Salinger's short stories. "Perhaps if we understood the INTENT of the code, we could understand which branches are allowed and which are not allowed, which data good, and which data evil?" This is literally the level of conversation. But you do not need exploits to hack. Sometimes you just have to be in the right place, in the right time, with the right tools. For example, as demonstrated here: https://vimeo.com/136964755 -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From darkpassenger at unseen.is Tue Aug 25 16:11:52 2015 From: darkpassenger at unseen.is (Darkpassenger) Date: Tue, 25 Aug 2015 13:11:52 -0700 Subject: [Dailydave] The Stone Mind In-Reply-To: <55DB29CB.3030403@immunityinc.com> References: <55DB29CB.3030403@immunityinc.com> Message-ID: <25789b1dd0219dae865c9f1e45e58393@unseen.is> code and data are not the only role players of a hack or cyber aggression . i suppose when we are quoting a monk , bits of philosophy in a tech mail list is tolerable , particularly when it meets the edgy developments of string theory . in short , Yamani "wisdom" or as in Farsi we call him by original name????? ??????? has a view on this issue . in short it circulate around a verse of Koran that says ???? ?????? ?? ??? ? ?? ??? ?????? ??? ???? ???? ????? . this is the essence of "Human Element" of the game . "Hekmah" (deep wisdom beyond common knowledge ) can not be regulated and no license is going to control and "govern" a game involving intelligent human intention to break out of a civilization to protect another one . the art of dealing with intelligent or average stupid commonly under humint umbrella builds power around ???? not retard registration forms . a while ago in this list somebody named bas said something about somewhere hackers have shit to do . the statement was too smart i suppose there were many retweets . the last part of the quoted verse says whoever is given the wisdom is given the best of the bests ( my translation ) On 2015-08-24 07:27, Dave Aitel wrote: > Lately in the exciting world of politics and regulation there's been a > lot of focus on the nature of what an exploit is, which is a bit like > watching collage freshman wrestle with a subtle zen-koan > buried in one > of > J.D. Salinger's short stories. "Perhaps if we understood the INTENT of > the code, we could understand which branches are allowed and which are > not allowed, which data good, and which data evil?" This is literally > the level of conversation. > > But you do not need exploits to hack. Sometimes you just have to be in > the right place, in the right time, with the right tools. > > For example, as demonstrated here: > https://vimeo.com/136964755 > > -dave > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunityinc.com > https://lists.immunityinc.com/mailman/listinfo/dailydave From nullcon at nullcon.net Wed Aug 26 01:41:28 2015 From: nullcon at nullcon.net (nullcon) Date: Wed, 26 Aug 2015 11:11:28 +0530 Subject: [Dailydave] nullcon se7en CFP is open Message-ID: Dear Friends, Welcome to nullcon se7en! $git commit -a := wrath | pride | lust | envy | greed | gluttony | sloth nullcon is an annual security conference held in Goa, India. The focus of the conference is to showcase the next generation of offensive and defensive security technology. We happily open doors to researchers and hackers around the world working on the next big thing in security and request everyone to answer our CFP and submit their new research. Time to tickle your gray cells and submit your research. Training: 2nd-3rd Mar 2016 Conference: 4th-5th Mar 2016 CFP se7en ============== Tips ==== 1. Submit early - Submitting early increases the chance of acceptance in the first round itself. The more you delay the more competition you have with other papers that are submitted later. 2. Technical description - The more concrete technical details you provide the better chance you have of getting accepted. Reviewers usually give low score to submissions that have very small or vague abstract and may not request for more details. The best way is to provide a supporting full technical paper that explains all the vulnerabilities, exploits etc in detail. 3. Declining a paper - Please take rejection as a suggestion for improvement somewhere in the paper and not as an offense. Declining a paper does not mean your submission is not good. There are many parameters we look at when reviewing a paper, technical depth is only one of them. Many times we have to let go of really good talks because there is already an accepted paper on similar subject or too many good submissions. We want you to succeed and are only trying to help you in preparing you for future submissions. So, cheer up and get ready for the next submission. 4. Review comments - We do not ask our review board for comments. If they have any comments, they write it down which we usually pass to the submitters. So, if we have comments we will pass it on. You don't have to specifically ask for review comments. Also, for small and vague abstracts, or talks delivered previously we do not share any review comments. Submission Type ================== Submit under any of the below Type - Talk (40 mins - 1 hr) - Event (Sub-events, Competitions, CTFs, BOFs) - Recreation (Fun events, Games, Parties, Tech Rock bands, Djs etc) - Tutorial (2-3hrs Workshops, hacking villages) Submission Topics ====================== Anything that aligns with our motto - "The neXt security thing!" is welcome. And as a special consideration for nullcon se7en any digital sin is also welcome ;) Categories ============= The talk time duration includes time for questions and answers (5-10 minutes) New Research Category (40 mins - 1 hr) - It is a deep knowledge technical track that includes new research, vulnerabilities, zero days or exploits. Desi Jugaad (30 mins - 1 hr) - It is our signature new research category talk and includes any local hacks. This category is dedicated to hackers who find innovative tech/non-tech solutions for real-life challenges. Current Research Category (30 mins - 1 hr) - It comprises of known security issues, case studies, twist to an existing research, tool, vulnerability, exploit or research-in-progress. Although this track is very technical, it covers known techniques, analysis and research already published or presented even though there might be some additions to it. Please note if you have already published, presented your research, it will fall in this category even though you have added new stuff to your research. Tool Category (30 mins - 1 hr) - It comprises of open source security tools, exploits, frameworks etc. This is an excellent opportunity for the original authors to showcase their software to the world. Event/Recreation Category (No specific time limit) - This is for proposing any exciting sub-events as mentioned above in "Submission Type" Review ========== We have an external review panel that scores the papers and based on the scoring we take a call on acceptance of papers. Submission Format =================== Email the paper to: cfp at nullcon.net The subject should be: CFP Goa 2016 < Paper Title > Email Body: Name Twitter Handle Submission Type (Mentioned above i.e. Talk/event/recreation/tutorial) Category (Mentioned above i.e. new research/current research/tool/desi jugaad etc) Time required (including 5-10 mins of QA) Submission Title Country (and City) of residence Organization and Designation Contact Number Have you presented or submitted this paper at any other conference(s) or magazine(s)? Yes, No. If yes, where? and how this submission is different from the previous ones. Note that new research talks already given elsewhere or are due to be given elsewhere prior to nullcon will be considered as current research category talks unless they consist of cutting edge and ground breaking technology, which is at the judgment of the review committee. Are you releasing an open source tool? Yes/No. (If yes, please include the source code for review) Are you releasing an exploit? Yes/No. (If yes, please include the source and vulnerability details for review) Are you releasing a new vulnerability/Zero-day? Yes/No. (If yes, please send us the details, including reproduction procedure, for review) Why do you think your paper is different/innovative (for all tracks) and how does it qualify as new work/research(for Research track only)? Are there any live demonstrations (These earn you good points during review)? Yes/No. (If Yes, how many? Also please explain each demo) If it is a talk, can it be converted to a workshop/village? Yes/No. (Sometimes there are good talks that may not be accepted due to large no. of submissions but can be accepted as a workshop) Brief Profile ( less than or equal to 500 Words) Paper Abstract - Please provide detailed working or your research/work. The more details you provide the better it is for the reviewers. Please keep the abstract to the point. Please do not try to hide the technical details or say "I can't disclose it till bla bla" as it does not help the reviewers in any way and may give your paper a low score because of insufficient information available in the abstract. Supporting technical details (Please attach full technical paper for review) - This is not a must if your abstract is technical and large enough for reviewers to understand your research fully. However, providing a full technical paper increases the chances of acceptance as reviewers get a better understanding of the technical capability. Your high resolution photo (attached) Note ======== Only the original authors should submit their research and any submission from a third party will be rejected. The Abstract should clearly mention the techniques and hacks in detail and merely mentioning that it works will not help in understanding the research to its full extent. nullcon is an open knowledge/research sharing platform and hence product/company marketing and pitches will be rejected. We request you not to submit any product specific talk. Important Dates CFP opens: 24th Aug 2015 1st round of speaker list Online: 15th Oct 2015 CFP closing date: 30th Nov 2015 Final speakers list online: 10th Dec 2015 Detailed paper submission by selected speakers: 6th Jan 2016 Training dates: 2nd-3rd Mar 2016 Conference dates: 4th-5th Mar 2016 Speaker Benefits ===================== For the New Research and Desi Jugaad Category --------------------------------------------- - Travel Reimbursement (Either actuals or the below mentioned amounts, whichever is less) - International Speaker (USD $1000) - National Speaker (INR Rs.6000) - Complimentary Accommodation for 3 nights. - Complimentary VIP conference pass. - One extra complementary Student pass to be given to any student who cannot afford to register. The student needs to show a valid and original College/University ID at the registration desk. Only university and colleges are applicable i.e. short term courses/certifications are not valid. - Invitation to speaker party. - Invitation to Mehfil-E-Mausiqi (nullcon networking cocktail). For the Current Research, Event and Tool Category ------------------------------------------- - Complimentary shared accommodation near the venue for 2 nights. - Complimentary VIP conference pass. - One extra complementary Student pass to be given to any student who cannot afford to register. The student needs to show a valid and original College/University ID at the registration desk. Only university and colleges are applicable i.e. short term courses/certifications are not valid. - Invitation to speaker party. - Invitation to Mehfil-E-Mausiqi (nullcon networking cocktail) * Only one speaker will be eligible for the benefits in case there are two or more speakers for a talk. ** By submitting a paper and agreeing to talk at nullcon you give Payatu Technologies Pvt. Ltd. the right to post, publish, re-distribute online and offline, soft and/or hard copies of your presentation material including slides, source code, detailed paper and the recorded video of the presentation and you. Regards, Aseem | Murtuja | Antriksh Unorganizers of nullcon From dave at immunityinc.com Thu Aug 27 11:11:28 2015 From: dave at immunityinc.com (Dave Aitel) Date: Thu, 27 Aug 2015 11:11:28 -0400 Subject: [Dailydave] INFILTRATE Contests: BINNAVI Message-ID: <55DF28A0.7050204@immunityinc.com> Every year, from HackCup to various coding challenges, we like to think of unique ways you can join us at THE BEST SECURITY CONFERENCE here in Miami next April 7th and 8th. We are starting this year with two new contests now that BinNavi is Open Sourced: 1. If you and your friends add Capstone (or another disassembler/analyzer) to BinNavi, to remove the IDA requirement, then we will send you three free tickets to INFILTRATE 2016! 2. If you and your friends integrate a decompiler with BinNavi, then we will also send you three free tickets to INFILTRATE 2016! If you do both, you get six free tickets to INFILTRATE. Because you are awesome. Go get typey typing. Dave Aitel Immunity, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From dave at immunityinc.com Thu Aug 27 14:17:38 2015 From: dave at immunityinc.com (Dave Aitel) Date: Thu, 27 Aug 2015 14:17:38 -0400 Subject: [Dailydave] Hacking Scalability Message-ID: <55DF5442.1030804@immunityinc.com> New INNUENDO Video is here: https://vimeo.com/137408741 Imagine you have hacked five hundred various boxes in some company that happens to have a lot of industrial equipment spinning really fast for some reason. And you want to group them automatically into which physical rooms they are all in. So you tell them all: At 5:45pm everyone listen to your microphones for 30 seconds. Then send that data back to me. Then you see who has the same ambient noise, and group them all together. So your operators come in the next day, and they have their INNUENDO GUI (the new one is demoed in the video above) automatically grouped and labeled for them. That's the sort of advanced modeling you will do with INNUENDO that you can't do with traditional penetration testing tools, and you can do it securely, over DNS or Outlook or any number of other protocols. The main difference is asynchronicity. Most penetration testing tools focused their design on exploits, not exfiltration. But making asynchronicity simple enough to use at any scale is extremely difficult. This is what Miguel's GUI design is great at, and if you want to try it out let me know and we can set up a trial of INNUENDO so you can run your own tests. :) -dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From HalVar at gmx.de Fri Aug 28 17:44:54 2015 From: HalVar at gmx.de (Halvar Flake) Date: Fri, 28 Aug 2015 23:44:54 +0200 Subject: [Dailydave] INFILTRATE Contests: BINNAVI In-Reply-To: <55DF28A0.7050204@immunityinc.com> References: <55DF28A0.7050204@immunityinc.com> Message-ID: Hey all, I haven't gotten around to finishing it yet, but I have begun writing a few small documents that explain what is needed to write a disassembly to the BinNavi database (e.g. that does what the IDA exporter currently does). There are 3 files planned: README_SQL // The general format of the disassembly README_TYPES // Peculiarities for those that want a type system README_OPERANDS // How to write BinNavi's "operand trees" At the moment, only a work-in-progress version of README_SQL exists. Once the files are semi-ready, they will be placed on github. In the meantime, and because Dave called this (awesome!) contest, here is the work-in-progress version version of README_SQL, in the hope of helping people get started. =================================================== Writing Disassemblies into the Database for BinNavi =================================================== At the moment, BinNavi depends on other disassemblers to provide the disassembly and CFGs to display - the current codebase ships with a binary blob IDA Pro plugin that exports IDA disassemblies into the database. In an ideal world, BinNavi would be able to perform disassembly itself, or at least have more connectivity to other tools that can generate such dis- assemblies. This is not an ideal world yet. This file is an attempt at documenting the process of writing a disassembly into the Postgres database in the same way that the IDA exporter does it. ===================== How to read this file ===================== The format of this file is a commented log of Postgresql statements with explanations about what data is written how, and why. There is some legacy cruft in the structure of the database, and some of our design choices were dubious, but such is the nature of any large codebase written by kids in their early-to-mid-20s. Most of this stuff is relatively straightforward, I hope the complicated bits can be explained. create schema "public" set search_path to "public" create table "modules" ( "id" serial, "name" text not null, "architecture" varchar(32) not null, "base_address" bigint not null, "exporter" varchar(256) not null, "version" int not null, "md5" char(32) not null, "sha1" char(40) not null, "comment" text, "import_time" timestamp not null default current_timestamp, primary key ("id")); begin lock table "modules" in access exclusive mode select coalesce(max(id), 0) + 1 from modulesi -- Get the ID for the new module -- to insert. select count(*) from modules select count(*) from modules where id = $1::int limit 1 insert into modules values( $1::int, -- The new module ID, for example '3'. $2::text, -- The name of the module, for example 'foobar.dll'. $3::varchar, -- Description string for the CPU arch: 'x86-32'. $4::bigint, -- Base address in virtual memory of the module. $5::varchar, -- Name of the tool writing the module. $6::int, -- Version of the tool. For some reason, '7' (?). $7::varchar, -- MD5 of the input file. $8::varchar, -- SHA1 of the input file. '', -- Per-module comment string. now()) -- Current timestamp for the module. commit begin -- Clean all the tables for the new module with ID '3'. -- TODO: It seems a number of tables (for the type system) were added later to -- the exporting code, but they do not appear to be deleted in this step. drop table if exists "ex_3_address_comments" drop table if exists "ex_3_address_references" drop table if exists "ex_3_expression_substitutions" drop table if exists "ex_3_operands" drop table if exists "ex_3_expression_tree_nodes" drop table if exists "ex_3_expression_trees" drop table if exists "ex_3_expression_nodes" drop table if exists "ex_3_control_flow_graphs" drop table if exists "ex_3_callgraph" drop table if exists "ex_3_basic_block_instructions" drop table if exists "ex_3_instructions" drop table if exists "ex_3_basic_blocks" drop table if exists "ex_3_functions" drop table if exists "ex_3_type_renderers" drop table if exists "ex_3_base_types" drop table if exists "ex_3_types" drop table if exists "ex_3_sections" drop table if exists "ex_3_type_substitution_paths" ------------------------------------------------------------------------------ -- Re-create these tables for the module. ------------------------------------------------------------------------------ -- The table for functions. create table "ex_3_functions" ( "address" bigint not null, -- Virtual address of the function "name" text not null, -- "demangled_name" text null default null, "has_real_name" boolean not null, "type" int not null default 0 check( "type" in ( 0, 1, 2, 3, 4 )), "module_name" text null default null, "stack_frame" int null default null, "prototype" int null default null) create table "ex_3_basic_blocks" ( "id" int not null, "parent_function" bigint not null, "address" bigint not null) create table "ex_3_instructions" ( "address" bigint not null, "mnemonic" varchar( 32 ) not null, "data" bytea not null) create table "ex_3_basic_block_instructions" ( "basic_block_id" int not null, "instruction" bigint not null, "sequence" int not null) create table "ex_3_callgraph" ( "id" serial, "source" bigint not null, "source_basic_block_id" int not null, "source_address" bigint not null, "destination" bigint not null) create table "ex_3_control_flow_graphs" ( "id" serial, "parent_function" bigint not null, "source" int not null, "destination" int not null, "type" int not null default 0 check( "type" in ( 0, 1, 2, 3 ))) create table "ex_3_expression_trees" ( "id" serial) create table "ex_3_expression_nodes" ( "id" serial, "type" int not null default 0 check( "type" >= 0 and "type" <= 7 ), "symbol" varchar( 256 ), "immediate" bigint, "position" int, "parent_id" int check( "id" > "parent_id" )) create table "ex_3_expression_tree_nodes" ( "expression_tree_id" int not null, "expression_node_id" int not null) create table "ex_3_operands" ( "address" bigint not null, "expression_tree_id" int not null, "position" int not null) create table "ex_3_expression_substitutions" ( "id" serial, "address" bigint not null, "position" int not null, "expression_node_id" int not null, "replacement" text not null) create table "ex_3_address_references" ( "address" bigint not null, "position" int null, "expression_node_id" int null, "destination" bigint not null, "type" int not null default 0 check( "type" >= 0 and "type" <= 8 )) create table "ex_3_address_comments" ( "address" bigint not null, "comment" text not null) drop type if exists "ex_3_type_category" create type "ex_3_type_category" as enum ('atomic', 'pointer', 'array','struct', 'union', 'function_pointer') create table "ex_3_base_types" ( "id" integer not null, "name" text not null, "size" integer not null, "pointer" integer, "signed" bool, "category" "ex_3_type_category" not null) create table "ex_3_types" ( "id" serial not null, "name" text not null, "base_type" integer not null, "parent_id" integer, "offset" integer, "argument" integer, "number_of_elements" integer) drop type if exists "ex_3_type_renderers_renderer_type" create type "ex_3_type_renderers_renderer_type" as enum ('integer','floating point', 'boolean', 'ascii', 'utf8', 'utf16') create table "ex_3_type_renderers" ("type_id" int not null,"renderer" "ex_3_type_renderers_renderer_type" not null) drop type if exists "ex_3_section_permission_type" create type "ex_3_section_permission_type" as enum ('READ', 'WRITE','EXECUTE', 'READ_WRITE', 'READ_EXECUTE', 'WRITE_EXECUTE','READ_WRITE_EXECUTE') create table "ex_3_sections" ("id" serial not null,"name" text not null,"start_address" bigint not null,"end_address" bigint not null,"permission" "ex_3_section_permission_type" not null,"data" bytea not null) create table "ex_3_expression_types" ("address" bigint not null,"position" integer not null,"expression_id" integer not null,"type" integer not null,"path" integer[] not null,"offset" integer) create table "ex_3_expression_type_instances" ("address" bigint not null,"position" integer not null,"expression_node_id" integer not null,"type_instance_id" integer not null) create table "ex_3_type_instances" ("id" integer not null,"name" text not null,"section_offset" bigint not null,"type_id" integer not null,"section_id" integer not null) create table "ex_3_type_substitution_paths" ("id" integer not null,"child_id" integer,"type_id" integer not null) ------------------------------------------------------------------------------ -- Done creating the tables. Now Re-create these tables for the module. ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ -- Insert the raw data for the memory sections in this module. Repeat this for -- each memory section ------------------------------------------------------------------------------ insert into "ex_3_sections" ( "id", "name", "start_address", "end_address", "permission", "data") values ($1::integer, $2::text, $3::bigint, $4::bigint, $5::ex_3_section_permission_type, $6::bytea) ------------------------------------------------------------------------------ -- Insert the type system into the database. This should be ignored initially, -- as BinNavi will work happily without any type system. Please refer to the -- yet-to-be written README_TYPES for a description of the tables for the type -- system. Simply make sure these tables exist, but leave them empty, for an -- initial go at exporting. ------------------------------------------------------------------------------ -- Insert basic (root) types. insert into "ex_3_base_types" ( "id", "name", "size", "pointer", "signed", "category") values (...) insert into "ex_3_types" ( "id", "name", "base_type", "parent_id", "offset", "argument", "number_of_elements") values (...) insert into "ex_3_expression_types" ( "address", "position", "expression_id", "type", "path", "offset") values (268720502,0,15,789,'{ 2998 }',128),(...) insert into "ex_3_type_instances" ( "id", "section_offset", "type_id", "section_id", "name") values (422,0,6,3,'unk_1005F000'),(...) insert into "ex_3_expression_type_instances" ( "address", "position", "expression_node_id", "type_instance_id") values (268439554,0,10247,1468),(...) ------------------------------------------------------------------------------ -- Insert per-instruction comments into the database. This is very straight- -- forward. ------------------------------------------------------------------------------ insert into "ex_3_address_comments" values (268439583,'unsigned int'),(...) ------------------------------------------------------------------------------ -- Operands are added by inserting the address of the instruction, the ID of -- the "expression tree" describing the operand, and the position in the ins- -- struction where the operand belongs. Please see the yet-to-be-written -- README_OPERANDS for details about the operand tree structure. ------------------------------------------------------------------------------ insert into "ex_3_operands" values (268439552,37,0),(268439554,10766,0),(...) ------------------------------------------------------------------------------ -- Instructions are identified by their address, and are simple otherwise. ------------------------------------------------------------------------------ insert into "ex_3_instructions" values (268439552,'push',decode('6AFF','hex')) ------------------------------------------------------------------------------ -- Insert functions. ------------------------------------------------------------------------------ insert into "ex_3_functions" values (268439552, -- address of the function. 'sub_10001000', -- non-demangled name of the function. null, -- demangled name, if available. false, -- set this true if the name is sensible. 0, -- type of the function. -- NORMAL = 0; // Regular function w/ full disassembly. -- LIBRARY = 1; // Statically linked -- IMPORTED = 2; // Not real code, just a DWORD ptr. -- THUNK = 3 // A thunk function, forwarding via an -- // uncondional jump. -- INVALID = 4 // A function contianing invalid code or -- // otherwise suspect stuff 'Onix32.dll', -- The name of the module this function belongs to. 26, -- An ID referencing the type describing the stack frame. -- Can be null if you do not have a type system. 1230), -- An ID referencing the type describing the function. -- Can also be null if you do not have a type system. (...) insert into "ex_3_basic_blocks" values (1, -- ID of the basic block. 268439552, -- Address of the function this basic block belongs to. 268439552), -- Address of the basic block. (...) ------------------------------------------------------------------------------ -- Basic blocks can contain arbitrary sequences of instructions - even non- -- consecutive. This is useful for things such as purging garbage instructions -- from obfuscated code, or reordering instructions for easier reading. ------------------------------------------------------------------------------ insert into "ex_3_basic_block_instructions" values (1, -- ID of the basic block an instruction belongs to. 268439552, -- Address of the instruction that belongs to the block. 0), -- Sequence index of the instruction, starting at 0. (...) ------------------------------------------------------------------------------ -- CFGs for a given function are constructed by simply listing edges between -- the basic blocks of that function, along with an edge type. ------------------------------------------------------------------------------ insert into "ex_3_control_flow_graphs" ("parent_function", "source", "destination", "type") values (268439552, -- Address of the parent function. 1, -- Basic block ID of the source block. 2, -- Basic block ID of the destination block. 1), -- Type of the edge. Valid types are: -- CONDITION_TRUE = 0 -- CONDITION_FALSE = 1 -- UNCONDITIONAL = 3 -- SWITCH = 4 (...) ------------------------------------------------------------------------------ -- Writing the callgraph writes edges between the functions in the executable. ------------------------------------------------------------------------------ insert into "ex_3_callgraph" ("source", "source_basic_block_id", "source_address", "destination") values (268439552, -- Address of the function in which the edge originates. 1, -- ID of the basic block in which the edge originates. 268439598, -- Address of the originating instruction. 268720341), -- Address of the target of this edge. (...) ------------------------------------------------------------------------------ -- Now comes the ugly part of writing an executable - writing operands for the -- instructions. This is much more involved than one would like, but given -- that the only "common" data structure that will accomodate the different -- operand structures possible on various CPUs are essentially arbitrary trees -- of expressions, the complexity is not entirely avoidable. ------------------------------------------------------------------------------ insert into "ex_3_expression_nodes" values (14282, 2, -- Currently valid types of nodes: -- SYMBOL = 1; // String to be displayed. -- IMMEDIATE_INT = 2; -- IMMEDIATE_FLOAT = 3; -- OPERATOR = 4; // '+', '*' etc. -- REGISTER = 5; -- SIZE_PREFIX = 6; // 'B4, 'B8', etc. -- DEREFERENCE = 7; // Memory dereference. null, -- Symbol string if applicable. 268687200, -- If this is a constant/immediate, the value. 0, -- The position within the operand. This means that -- in a string like [esp+eax+6450h+var_63D0], the 1), -- ID of the parent node in the tree. (...) insert into "ex_3_expression_trees" values (15063),(15062),(15060),(15058),(15054),(15051),(15050),(15048),(15047),(15045),(15044),(15042),(15040),(15039),(15034),(15033),(15030),(15028),(15027),(15026),(15025),(15023),(15016),(15011),(15010),(15007),(15006),(15004),(15002),(15001),(15000),(14999),(14998),(14996),(14995),(14992),(14990),(14988),(149 insert into "ex_3_expression_tree_nodes" values (15063,1),(15063,14285),(15062,1),(15062,14284),(15060,1),(15060,14282),(15058,1),(15058,14280),(15054,1),(15054,14276),(15051,1),(15051,14273),(15050,1),(15050,14272),(15048,1),(15048,14270),(15047,1),(15047,14269),(15045,1),(15045,14267),(15044,1),(15044,14266),(15042,1),(15042,14264),(15040,1),(1504 create table "ex_3_expression_trees" ( "id" serial) create table "ex_3_expression_nodes" ( "id" serial, "type" int not null default 0 check( "type" >= 0 and "type" <= 7 ), "symbol" varchar( 256 ), "immediate" bigint, "position" int, "parent_id" int check( "id" > "parent_id" )) create table "ex_3_expression_tree_nodes" ( "expression_tree_id" int not null, "expression_node_id" int not null) create table "ex_3_operands" ( "address" bigint not null, "expression_tree_id" int not null, "position" int not null) -- Create indices on the tables now that they contain data. create unique index "ex_3_functions_address_idx" on "ex_3_functions"( "address" ) create unique index "ex_3_basic_blocks_id_idx" on "ex_3_basic_blocks"( "id" ) create index "ex_3_basic_blocks_address_idx" on "ex_3_basic_blocks"( "address" ) create unique index "ex_3_instructions_address_idx" on "ex_3_instructions"( "address" ) create unique index "ex_3_expression_trees_id_idx" on "ex_3_expression_trees"( "id" ) create unique index "ex_3_expression_nodes_id_idx" on "ex_3_expression_nodes"( "id" ) insert into "ex_3_expression_substitutions" ("address", "position", "expression_node_id", "replacement") values (268720405,1,737,'esp+arg_4'),(268724748,1,737,'esp+var_20'),(268724778,1,737,'esp+var_20'),(268725269,0,3008,'esp+var_8'),(268725272,1,3008,'esp+var_8'),(268725329,0,3008,'esp+var_8'),(268725332,1,3008,'esp+var_8'),(268725392,0,3008,'esp+ SELECT 1 SELECT 1 insert into "ex_3_address_references" values (268439554,0,10247,268779723,7),(268439598,0,4085,268720341,4),(268439620,0,1,268439622,1),(268439620,0,10249,268439641,0),(268439630,0,4152,268612576,4),(268439639,0,10275,268439645,2),(268439659,0,1,268439661,1),(268439659,0,10250,268439690,0),(268439693,0,1,268439695,1),(268439693,0,10251,268439724,0), delete from ex_3_instructions as instructions using ex_3_basic_block_instructions as basic_block_instructions where basic_block_instructions.instruction = instructions.address and basic_block_id is null; delete from ex_3_basic_block_instructions where basic_block_id is null; delete from ex_3_address_references where address in ( select address from ex_3_address_references except select address from ex_3_instructions) SELECT 1 delete from ex_3_address_comments where address in ( select address from ex_3_address_comments except select address from ex_3_instructions) delete from ex_3_expression_substitutions where address in ( select address from ex_3_expression_substitutions except select address from ex_3_instructions) delete from ex_3_operands where address in ( select address from ex_3_operands except select address from ex_3_instructions) delete from ex_3_expression_type_instances where address in ( select address from ex_3_expression_type_instances except select address from ex_3_operands) alter table "ex_3_functions" add primary key( "address" ) alter table "ex_3_basic_blocks" add primary key( "id" ) alter table "ex_3_basic_blocks" add constraint "ex_3_basic_blocks_parent_function_fkey" foreign key ( "parent_function" ) references "ex_3_functions"( "address" ) on delete cascade on update cascade alter table "ex_3_instructions" add primary key( "address" ) alter table "ex_3_basic_block_instructions" add constraint "ex_3_basic_block_instructions_bb_fkey" foreign key ( "basic_block_id" ) references "ex_3_basic_blocks"( "id" ) on delete cascade on update cascade SELECT 1 alter table "ex_3_basic_block_instructions" add constraint "ex_3_basic_block_instructions_ins_fkey" foreign key ( "instruction" ) references "ex_3_instructions"( "address" ) on delete cascade on update cascade alter table "ex_3_callgraph" add primary key( "id" ) alter table "ex_3_callgraph" add constraint "ex_3_callgraph_source_fkey" foreign key ( "source" ) references "ex_3_functions"( "address" ) on delete cascade on update cascade alter table "ex_3_callgraph" add constraint "ex_3_callgraph_destination_fkey" foreign key ( "destination" ) references "ex_3_functions"( "address" ) on delete cascade on update cascade alter table "ex_3_callgraph" add constraint "ex_3_callgraph_source_basic_block_id_fkey" foreign key ( "source_basic_block_id" ) references "ex_3_basic_blocks"( "id" ) on delete cascade on update cascade alter table "ex_3_callgraph" add constraint "ex_3_callgraph_source_address_fkey" foreign key ( "source_address" ) references "ex_3_instructions"( "address" ) on delete cascade on update cascade alter table "ex_3_control_flow_graphs" add primary key( "id" ) alter table "ex_3_control_flow_graphs" add constraint "ex_3_control_flow_graphs_parent_function_fkey" foreign key ( "parent_function" ) references "ex_3_functions"( "address" ) on delete cascade on update cascade alter table "ex_3_control_flow_graphs" add constraint "ex_3_control_flow_graphs_source_fkey" foreign key ( "source" ) references "ex_3_basic_blocks"( "id" ) on delete cascade on update cascade alter table "ex_3_control_flow_graphs" add constraint "ex_3_control_flow_graphs_destination_fkey" foreign key ( "destination" ) references "ex_3_basic_blocks"( "id" ) on delete cascade on update cascade alter table "ex_3_expression_trees" add primary key( "id" ) alter table "ex_3_expression_nodes" add primary key( "id" ) alter table "ex_3_expression_nodes" add constraint "ex_3_expression_nodes_parent_id_fkey" foreign key ( "parent_id" ) references "ex_3_expression_nodes"( "id" ) on delete cascade on update cascade SELECT 1 alter table "ex_3_expression_tree_nodes" add constraint "ex_3_expression_tree_nodes_expression_tree_id_fkey" foreign key ( "expression_tree_id" ) references "ex_3_expression_trees"( "id" ) on delete cascade on update cascade alter table "ex_3_expression_tree_nodes" add constraint "ex_3_expression_tree_nodes_expression_node_id_fkey" foreign key ( "expression_node_id" ) references "ex_3_expression_nodes"( "id" ) on delete cascade on update cascade alter table "ex_3_operands" add primary key ( "address", "position" ) alter table "ex_3_operands" add constraint "ex_3_operands_expression_tree_id_fkey" foreign key ( "expression_tree_id" ) references "ex_3_expression_trees"( "id" ) on delete cascade on update cascade alter table "ex_3_operands" add constraint "ex_3_operands_address_fkey" foreign key ( "address" ) references "ex_3_instructions"( "address" ) on delete cascade on update cascade SELECT 1 alter table "ex_3_expression_substitutions" add constraint "ex_3_expression_substitutions_address_position_fkey" foreign key ( "address", "position" ) references "ex_3_operands"( "address", "position" ) on delete cascade on update cascade alter table "ex_3_expression_substitutions" add constraint "ex_3_expression_substitutions_expression_node_id_fkey" foreign key ( "expression_node_id" ) references "ex_3_expression_nodes"( "id" ) on delete cascade on update cascade alter table "ex_3_address_references" add constraint "ex_3_address_references_address_position" foreign key ( "address", "position" ) references "ex_3_operands"( "address", "position" ) on delete cascade on update cascade alter table "ex_3_address_references" add constraint "ex_3_address_references_expression_node_id_fkey" foreign key ( "expression_node_id" ) references "ex_3_expression_nodes"( "id" ) on delete cascade on update cascade alter table "ex_3_base_types" add primary key ( "id" ) alter table "ex_3_base_types" add constraint "ex_3_base_types_pointer_fkey" foreign key ( "pointer" ) references "ex_3_base_types"( "id" ) on delete cascade on update cascade deferrable initially deferred alter table "ex_3_types" add primary key ( "id") alter table "ex_3_types" add constraint "ex_3_types_parent_id_fkey" foreign key ( "parent_id" ) references "ex_3_base_types" ( "id" ) on delete cascade on update cascade deferrable initially deferred alter table "ex_3_types" add constraint "ex_3_types_base_type_fkey" foreign key ( "base_type" ) references "ex_3_base_types" ( "id" ) on delete cascade on update cascade alter table "ex_3_expression_types" add primary key ( "address", "position", "expression_id" ) alter table "ex_3_expression_types" add constraint "ex_3_expression_type_type_fkey" foreign key ( "type" ) references "ex_3_base_types" ( "id" ) on update no action on delete cascade deferrable initially deferred alter table "ex_3_sections" add primary key ( "id" ) alter table "ex_3_type_instances" add primary key ( "id" ) alter table "ex_3_type_instances" add constraint ex_3_type_instances_type_id_fkey foreign key ( "type_id" ) references ex_3_base_types ( "id" ) match simple on update cascade on delete cascade alter table "ex_3_type_instances" add constraint ex_3_type_instances_section_id_fkey foreign key ( "section_id" ) references ex_3_sections ( "id" ) match simple on update cascade on delete cascade SELECT 1 alter table "ex_3_expression_type_instances" add primary key ( "address", "position", "expression_node_id" ) alter table "ex_3_expression_type_instances" add constraint "ex_3_expression_type_instances_type_instance_id_fkey" foreign key ( "type_instance_id" ) references ex_3_type_instances ( "id" ) match simple on update cascade on delete cascade alter table "ex_3_expression_type_instances" add constraint "ex_3_expression_type_instances_address_position_fkey" foreign key ( "address", "position" ) references ex_3_operands ( "address", "position" ) match simple on update cascade on delete cascade alter table "ex_3_expression_type_instances" add constraint "ex_3_expression_type_instances_expression_node_id_fkey" foreign key ( "expression_node_id" ) references ex_3_expression_nodes ( "id" ) match simple on update cascade on delete cascade deallocate all commit vacuum analyze "ex_3_operands" SELECT 1 vacuum analyze "ex_3_functions" vacuum analyze "ex_3_basic_blocks" vacuum analyze "ex_3_instructions" SELECT 1 vacuum analyze "ex_3_basic_block_instructions" vacuum analyze "ex_3_callgraph" vacuum analyze "ex_3_control_flow_graphs" vacuum analyze "ex_3_expression_trees" vacuum analyze "ex_3_expression_nodes" SELECT 1 vacuum analyze "ex_3_expression_tree_nodes" vacuum analyze "ex_3_expression_substitutions" vacuum analyze "ex_3_address_references" vacuum analyze "ex_3_address_comments" vacuum analyze "ex_3_type_renderers" vacuum analyze "ex_3_base_types" vacuum analyze "ex_3_types" SELECT 1 vacuum analyze "ex_3_expression_types" vacuum analyze "ex_3_sections" SET extra_float_digits = 3 SELECT relname FROM pg_class WHERE relname = 'modules' SELECT 1 SELECT id, name FROM modules ORDER BY id SELECT 1 SELECT 1 SELECT count(*) AS fcount FROM ex_1_functions WHERE address <> 0 OR type <> 3 SELECT 1 SELECT count(*) AS fcount FROM ex_2_functions WHERE address <> 0 OR type <> 3 SELECT 1 select table_name from information_schema.tables where table_catalog = 'foss_navi_test5' SELECT 1 SELECT count(*) AS fcount FROM ex_3_functions WHERE address <> 0 OR type <> 3 select * from create_module($1,$2) as result '', $2 = '3' SELECT 1 SELECT id, bn_modules.name, md5, sha1, description, import_time, modification_date, image_base, file_base, stared, initialization_state FROM bn_modules WHERE id = 10 ORDER by id From rodrigo at kernelhacking.com Fri Aug 28 19:45:57 2015 From: rodrigo at kernelhacking.com (Rodrigo Rubira Branco (BSDaemon)) Date: Fri, 28 Aug 2015 16:45:57 -0700 Subject: [Dailydave] INFILTRATE Contests: BINNAVI In-Reply-To: <55DF28A0.7050204@immunityinc.com> References: <55DF28A0.7050204@immunityinc.com> Message-ID: <55E0F2B5.9070904@kernelhacking.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave, I really like this idea and the incentive that it creates, so I want to second that and say that the group/individual that completes 1 and 2 from Dave's proposal will also earn free tickets to H2HC 2015 and on (they can choose when they want to use the ticket). Additionally to that, I want to complement adding two more items into the bucket list: 3-) The IDA plugin that is currently not open-source, if someone writes an open-source version, same thing (also up to three members) 4-) Any code contributions to Grsecurity project that are accepted (trying to offer what I can to incentivize a real security project to keep going: http://grsecurity.net/announce.php). Best Regards, Rodrigo (BSDaemon). On 8/27/15 08:11, Dave Aitel wrote: > Every year, from HackCup to various coding challenges, we like to > think of unique ways you can join us at THE BEST SECURITY > CONFERENCE here in Miami next April 7th and 8th. > > We are starting this year with two new contests now that BinNavi is > Open Sourced: > > 1. If you and your friends add Capstone (or another > disassembler/analyzer) to BinNavi, to remove the IDA requirement, > then we will send you three free tickets to INFILTRATE 2016! > > 2. If you and your friends integrate a decompiler with BinNavi, > then we will also send you three free tickets to INFILTRATE 2016! > > If you do both, you get six free tickets to INFILTRATE. Because you > are awesome. Go get typey typing. > > Dave Aitel Immunity, Inc. > > > > > > > _______________________________________________ Dailydave mailing > list Dailydave at lists.immunityinc.com > https://lists.immunityinc.com/mailman/listinfo/dailydave > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXg8rUACgkQRpuC3B/O3qFrKQCfSJHR2oyNtrqbfCsQykFMXeCP MtYAn0F6jCUTiBs7z00tbBAGB2cjjgOK =j+da -----END PGP SIGNATURE-----