Correction: Clam *does* have some unpacking support

Correction of my last post: It appears that Clam has *some* unpacking support. It is not as comprehensive as some of us would like, but progress is being made :-)

ClamAV and unpackers

Hey all,

this might be a rather odd question, but given the (unfortunate) fact that ClamAV can't unpack
even the simplest packers, has nobody ever contemplated writing packer-specific unpackers
for ClamAV ?

Cheers,
Halvar

TAOSSA blog post I didn't see but will comment on :-)

http://taossa.com/index.php/2008/10/13/bugs-vs-flaws/#more-83

I didn't see this post beforehand, and I would like to comment on it (mainly because commenting on his blog post might be the easiest way of getting into a conversation with Mr. McDonald these days ;), but I don't have time right now. Will fix this later this week hopefully.

Sometimes, diffing can remove obfuscation (albeit rarely)

Hey all,

apologies for the sensationalist title, but I found another amusing example today where the same function was present in two different executables -- in two differently obfuscated forms. Amusingly, DiffDeluxe identified the "common components" between these two functions, effectively removing a lot of the obfuscation.


While this is clearly not a typical case, it nonetheless made me smile.

Merry Christmas everyone !

A good protocol attack ...

... is like a good joke. This one, while requiring special circumstances to succeed with high probability, was responsible for a lot of laughter on my side.

BinDiff / BinNavi User Forum

Hey all,

we have re-activated the BinDiff / BinNavi User Forum under

https://zynamics.fogbugz.com/default.asp?BinNavi
https://zynamics.fogbugz.com/default.asp?BinDiff

There is not a whole lot there at the moment, but that should change soon :)

Malicious Office/PDFs

Hey all,

for some research that I'm doing, I'm looking for a collection of malicious Office/PDF documents. If anyone has such documents (e.g. because he was targeted in an attack, or because he found one somewhere), I'd much appreciate submissions ! :)

BinNavi v2 and PHP !

Hey all,

we have written about the SQL storage format for BinNavi quite a few times on this blog, and how we'd like to encourage third parties to use it. I am quite happy to say that Stefan Esser of
SektionEins GmbH has built code to export PHP byte code into the database format. The (cute) results can be seen under

http://www.suspekt.org/2008/11/05/php-bytecode-in-binnavi-20/

German ways of expressing optimism

One of my favourite things when travelling and interacting people from other cultures is observing differences in conversational conventions -- and (most importantly) different forms and perceptions of "conversational humor". Aside from comedic protocol screw-ups (e.g. literally translating an essentially untranslateable expression to another language, earning -- at best -- puzzled looks and -- at worst -- thoroughly offending the conversation partner), it often provides interesting insights into one's own culture and habits.

This weeks special: German forms of expressing optimism.

There are many expressions in German that are horribly difficult to translate.

One of my favourites that could cause confusion is the German custom of wishing people luck by wishing them "Hals- und Beinbruch!" (literally: 'broken neck and broken leg') or 'Kopf- und Bauchschuss' (literally: 'shot in the head and stomach') or (for sailors) 'Mast- und Schotbruch' (literally: 'broken mast and ripped sail') upon parting.
A common reply for this would be "wird schon schiefgehen" (literally: 'I have no doubt it's going to go badly'). Counterintuitively, the semantics of this is optimistic -- e.g. whoever says that things are going to turn out badly indicates by this that he is not worried, and that he actually expects that things will be fine.

In essence, one expresses optimism by claiming that an improbably horrible outcome is a near-certainty.

Even though I try hard to not have an all-too-obvious German accent any more, I do catch myself all the time in using the above pattern, even though it does not translate. I (deservedly) earned puzzled looks today by clumsily attempting to use the following German saying to indicate my optimism about the future:

"Lächle und sei froh, sagten sie mir, denn es könnte schlimmer kommen. Und ich lächelte und war froh, und es kam schlimmer."

This has a certain elegance in German, which is totally lost in my clumsy translation:

"Smile and be happy, they told me, because things could be a lot worse. So I smiled and was happy, and things got a lot worse."

Aside from the clumsiness of the expression when translated, the semantics (e.g. the intention to express optimism) was thoroughly lost -- the effect was a thoroughly puzzled and slightly worried look by my conversation partner. I think it is situations like these where Germans earn their bad reputation for being thoroughly unfunny.

Other things that are good for causing confusion between a native English speaker who interacts with someone from the German-speaking world are differences when it comes to acceptable replies to the question "How are you ?". The usual form of this in German is "Wie gehts ?", essentially "How is it going ?". In the English speaking world, acceptable replies seem to be restricted to "good", "good good", or "great".

Proper replies to the question "How is it going" over here would be:
"Muss." -- literal translation: 'it has to somehow'
"Naja, ganz ok." -- 'well... ok ...'
"Könnte schlechter/besser gehen" -- 'could be worse/better'
"Bergauf" or "Bergab" -- uphill / downhill

If the other party feels inclined to have a longer chat, they could reply with
"Yesterday, we stood on a cliff. Today we have advanced by a significant step."
or "Katastrophe". This is usually followed with a short anecdote or complaint about something work-related. From a social perspective, this does wonders as an ice-breaker.

Whenever I catch myself in such a situation, I realize that no matter how much one travels, and no matter how much time one spends in a different cultural climate, certain components of the social interaction are nigh-impossible to change.

Anyhow, time to go to sleep.

The joys of the Volkswagen Caddy Natural Gas car

So I do own a car (contrary to what most people expect). About a year ago, I bought a VW Caddy EcoFuel. It runs on natural gas in normal mode and only uses the gasoline tank for starting (and when the natural gas has run out).

Up until 4 weeks or so ago I was pretty happy with it, but one morning, the car refused to start unless I hit the gas heavily while starting. I brought the car to the repair shop that belongs to the same place where I bought the car. After a few days of tinkering, they told me that

1. The particular car I own doesn't lock the tank when the rest of the car is locked and
2. Somebody poured an unidentifiable liquid into my tank causing the problems
3. Because this is not a problem with the car itself, warranty doesn't cover it
4. Removing the tank and the fuel pump and cleaning everything is going to cost 1200 EU

I am somewhat annoyed by some punk pouring an unidentifiable liquid into my tank and agree to pay the money. I also ask for the shop to retain a sample of the tank contents so I can at least find out what was poured into the tank, and perhaps get money back from my insurance.

They agree. When I come to pick up the car, the guys at the shop for some bizarre reason cannot find the sample. I sit and wait for ~1 hour, and they finally produce an unlabelled can from somewhere. Ok. I ask them to sign a piece of paper certifying that this sample is coming from my tank, and they tell me they will send it to me via regular mail the next day. So far so good.

So two weeks pass, and I call back 3 times for that piece of paper. At the beginning of the third week, I have to take my guinea pigs to the vet in the morning (yes, I don't only own a car, I also have guinea pigs). On my way back from the vet, the natural gas runs out, and the car switches to gasoline mode -- while I am going about 130km/h with a large truck behind me. The only complication: My engine switches off. Awesome.

So I manage to stop the car safely on the side of the autobahn and get towed to the next Volkswagen shop. About 2 hours after I leave my car there, I get a call from the repair guy there, telling me that they can see in the VW database which repairs were done on my car recently, but from what they can tell, these repairs never happened. They call in an expert that is certified to appear in court to take pictures & write a report, and he also confirms: The tank was never removed, the gasoline pump never replaced, and the 1200 EU were apparently charged without any of the stuff ever happening.

Clearly, I am somewhat surprised. To my dismay, I am also told that the actual repairs will cost about 2000 EU, and that there is still unidentified stuff in my tank.

So all in all, I am currently stuck with

1. 1200 EU for repairs that never happened
2. 2000 EU for repairs that are happening now
3. 2 * 300 EU for chemical analysis of the two samples taken
4. unspecified legal costs (most likely covered by my insurance) to deal with the situation

All in all, I am quite dissatisfied with VW on this front -- IMO they should've warned me that the tank doesn't lock, and they shouldn't have "VW Certified Repair Shops" that appear to attempt to defraud customers. I have trouble imagining that not actually performing the repairs was an "honest mistake" (although I usually live by the motto that "one should not attribute anything to malice that can be attributed to incompetence").

Anyhow, let's see how this plays out. As if I don't have other stuff to do.

For those playing with the printer bug...

... I can't help but post this small PNG. And since blogger rescales/blurs the picture, here is a link to the "full" one.

My bro's comments on the financial crisis

My brother wrote an article injecting some reality into the discussion about the banking crisis on Spiegel Online. The german version can be seen here. I'll share a short summary of his arguments here (and he'll complain about my distortions later ;).

Short version: The article describes why the situation is less dire than many pundits claim, and explains logical fallacies in commonly-heard arguments.

In the following, here's a summary of his arguments, in the form of "Myth --> Reality"

1. The US government is taking on a total of 7000bn in liabilities -- about 5500bn by agreeing to step in for Fannie Mae / Freddie Mac, and about 700bn in papers bought by doing the bailout. This equates to roughly half of US GDP, and since the US is already in debt by about 65% of GDP, this would push the total indebtedness of the US to be clearly past 100% of GDP. As a result, serious doubts would have to be cast on the US governments ability to repay debts and service interest on debt.
   Reality: Most of the 5500bn are backed by "proper" mortgages with decent quality. It is unclear whether the US gov will lose money on the Fannie Mae / Freddie Mac deal at all. Even the 700bn in "toxic assets" the US is willing to buy have some underlying value. Realistic expectations at the total loss for the US government in this deal runs in the area of 500bn, which would be less than 3% of GDP -- and therefore not a significant source of problems.
2. The liquidity that central banks are injecting into the markets should lead to hyperinflation. Reality: The measures to help liquidity in the markets do not increase the money supply in the long run. They are usually short-term credits given to struggling banks for a limited amount of time -- weeks or months. After this time, the creditors have to repay the loans, and the money disappears. At the same time, the willingness by existing banks to lend decreases, thus decreasing the money supply in the economy. The statistics by central banks show that the actual money supply M2 is growing a lot less slowly at the moment in spite of all the liquidity injections. Since the money supply is only growing very slowly at the moment, the inflationary pressures are low.
   
3. The banking crisis is responsible for the overall slowdown in the EU's economy, and the German government is thus not responsible for having to adjust their growth estimates downwards sharply.
   Reality: Most indicators show that the slowdown started way before the crisis reached it's current urgence. The indicators started pointing down much earlier as a result of the heavy increase in energy costs, the appreciation of the euro (and the resulting loss in competitiveness), and Germany's botched reform of accounting rules for writing down investments in equipment. The banking crisis is just the latest "kick" -- but the three previous ones were all known early (and could've been partially corrected).
4. This is the mother of all financial crises. This banking crisis is the worst crisis in several generations, up to the 1930's crash. Reality: Dramatic banking crises are more common than we think. Since 1970, the IWF has counted 42 crashes in countries like Argentina, Indonesia, China, Japan, Finland or Norway. In comparison to these crises, the current crisis isn't even very deep or expensive: The Paulson-bailout comes at a cost of 700bn, not even 5% of GDP, and only a fraction of this will be actually lost. According to the IWF, the average banking crisis in a country came at the cost of 13% of GDP for that country's tax payer. The Indonesian crisis even came in at four times this. The big difference to the other crises is that this one has caught on in the world's biggest economy, and as such reaches unknown dimensions in absolute terms.
   

A few things I forgot to mention :-)

Hey all,

I forgot to mention a few things in the previous post:

1. We're going to release BinDiff v2.1 on the 15th of October 2008. This is still the "old" diffing engine, albeit with a number of speed & reliability improvements.
2. We're going to release BinNavi v2.0 on the 15th of October 2008. The number of new features in this release is huge -- it's really quite significant. You can read about it in detail on SP's blog.
   I will post some more information myself in the next days. Just a few mouth-watering keywords: Plugin API to extend Navi from Java/JRuby/Jython/JavaScript, built-in intermediate language, hierarchical tagging / namespaces for structuring large disassemblies, cross-module-graphing, managing multiple address spaces in one project, many user interface improvements, faster IDA->SQL export etc. etc. etc.
3. The DiffDeluxe engine will be part of the next BinDiff release thereafter, probably no later than February 2008. If you are an existing BinDiff customer and would like to try the DiffDeluxe engine in order to provide us with feedback, do not hesitate to contact us -- it's available for testing now. We're especially interested in finding instances where DiffDeluxe performs worse than BinDiff v2.1. Switching the core diffing engine is a significant change, and I would not want to know of any instances where the new engine is worse than the old one.

Improving Binary Comparison (and it's implication for malware classification)

I am at Virus Bulletin in Ottawa -- if anyone wants to meet to see our new stuff, please drop mail to info@zynamics.com ! :)

It has been a while since I posted here -- partially because I had a lot of work to finish, partially because, after having finished all this work, I took my first long vacation in a ... very long while.

So I am back, and there are a number of things that I am happy to blog about. First of all, I now have in writing that I am officially an MSc in Mathematics. For those that care about obscure things like extending the euclidian algorithm to the ring of boolean functions, you can check the thesis here:
http://www.zynamics.com/files/Diplomarbeit.Thomas.Dullien.Final.pdf

For those that are less crazy about weird computational algebra: Our team here at zynamics has made good progress on improving the core algorithms behind BinDiff further. Our stated goal was to make BinDiff more useful for symbol porting: If you have an executable and you suspect that it might contain a statically linked library for which you have source access (or which you have analyzed before), we want BinDiff to be able to port the symbols into the executable you have, even if the compiler versions and build environments differ significantly, and even if the versions of the library are not quite the same.

Why is this important ? Let's say you're disassembling some piece of network hardware, and you find an OpenSSL-string somewhere in the disassembled image. Let's say you're disassembling an old PIX image (6.34 perhabs) and see the string

OpenSSL 0.9.5a 1 Apr 2000

This implies that PIX contains OpenSSL, and that the guys at Cisco probably backported any fixes to OpenSSL to the 0.9.5a version. Now, it would be fantastic if we could do the following: Compile OpenSSL 0.9.5a with full symbols on our own machine, and then "pull-in" these symbols into our PIX disassembly.

While this was sometimes possible with the BinDiff v2.0 engine (and v2.1, which is still essentially the same engine), the results were often lacking in both speed and accuracy. A few months back, Soeren and I went back to the drawing board and thought about the next generation of our diffing engine -- with specific focus on the ability to compare executables that are "far from each other", that differ significantly in build environments etc. and that only share small parts of their code. The resulting engine (dubbed "DiffDeluxe" by Soeren) is significantly stronger at this task.

Why did the original BinDiff v2 engine perform poorly ? There are a number of reasons to this, but primarily because of the devastating impact that a "false match" can have on further matches in the diffing process, and due to the fact that in the described scenarios, most of the executable is completely different, and only small portions match. The old engine had a tendency to match a few of the "unrelated components" of each executable, and these initial incorrect matches led to further bad matching down the road.

This doesn't mean the BinDiff v2 engine isn't probably the best all-round diffing engine you can find (I think it is, even if some early builds of the v2.0 suffered from silly performance issues -- those of you that are still plagued by this please contact support@ for a fix !) -- but for this particular problem some old architectural assumptions had to be thrown overboard.

Anyhow, to cut a long story short: While the results generated by DiffDeluxe aren't perfect yet, they are very promising. Let's follow our PIX/OpenSSL scenario:

DiffDeluxe operates with two "fuzzy" values for each function match: "Similarity" and "Confidence". Similarity indiciates how successful the matching algorithm was in matching basic blocks and instructions within the two functions, and confidence indicates how "certain" DiffDeluxe is that this match is a correct one. This is useful to sort the "good" and "bad" matches, and to inspect results before porting comments/names. Anyhow, let's look at some high-confidence matches:


Well, one doesn't need to be a rocket scientist to see that these functions match. But in many situations, the similarity between two functions is not 100% evident: The following is a matched function with only 72% similarity (but 92% confidence):



So what is the overall result ? Out of the 3977 functions which we had in libcrypto.so, we were able to match 1780 in our Pix disassembly -- but with a big caveat: A significant number of these have very low similarity and confidence scores. This isn't surprising: The differences between the compiler used upon compile time of our Pix image (sometime 6 years ago ?) and the compiler we used (gcc 4.1, -O3) is drastic. All in all, we end up with around 250 high-confidence matches -- which is not too bad considering that we don't know how many functions from OpenSSL the Pix code actually contains.

In order to have a more clear idea of how well these algorithms perform, we need an example of which we know that essentially the entire library has been statically linked in. For this, luckily, we have Adobe Reader :-)

With all the Adobe patches coming up, let's imagine we'd like to have a look at the Javascript implementation in Acrobat Reader. It can be found in Escript.api. Now, I always presume that everybody else is as lazy as me, so I can't imagine Adobe wrote their own Javascript implementation. But when Adobe added Javascript to Acrobat Reader, there were few public implementations of Javascript around -- essentially only the engine that is nowadays known as "SpiderMonkey", e.g. the Mozilla Javascript engine. So I compiled SpiderMonkey into "libjs.so" on my Linux machine and disassembled Escript.api. Then I ran DiffDeluxe. The result:

Escript contains about 9100 functions, libjs.so contains about 1900. After running the diff, we get 1542 matches. Let's start verifying how "good" these matches are. As discussed above, DiffDeluxe uses a "similarity" and "confidence" score to rate matches. We get 203 matches with similarity and confidence above 90% -- for these functions, we can more or less blindly assume the matches are correct. If we have any doubts, we can inspect them:





























Well, there is little question that this match was accurate.

The interesting question is really: How low can we go similarity- and confidence-wise before the results start deteriorating too badly ? Let's go low -- for similarities below 40%. For example the js_ConcatStrings match.






























Manual inspection of the screenshot on the right will show that the code performs equivalent tasks, but that hardly any instructions remain identical.

Proceeding further down the list of matches, it turns out that results start deteriorating once both confidence and similarity drop below 0.3 -- but we have around 950 matches with higher scores, e.g. we have successfully identified 950 functions in Escript.api. While this is signifcantly less than the 1900 functions that we perhabs could have identified, it is still pretty impressive: After all, we do not know which exact version of SpiderMonkey was used to compile Escript.api, and significant changes could have been made to the code.

Clearly, we're a long way from matching 95% -- but we're very close to the 50% barrier, and will work hard to improve the 50% to 75% and beyond :-)

Anyhow, what does all this have to do with automatic classification and correlation of malware ?

I think the drastic differences induced by platform/compiler changes make it pretty clear that statistical measures that do not focus on the structure and semantics of the executable, but on some "simple" measure like instruction frequencies, fail. All the time. Behaviorial methods might have a role to play, but they will not help you one bit if you acquire memory from a compromised machine, and are trivially obfuscated by adding random noisy OS interaction.

I am happy to kill two birds with one stone: By improving the comparison engine, I am making my life easier when I have to disassemble Pix -- and at the same time, I am improving the our malware classification engine. Yay :-)

Anyhow, as mentioned above: I am at the Virus Bulletin conference -- if anyone wishes to have a chat or have our products demo'ed, please do not hesitate to send mail to info@zynamics.com.

My 100th blog post, and why my blog entries never have titles.


Hey all, this is my 100th blog post. And again, it has no title. This is not due to me feeling too cool to provide one, it's simply a matter of my "create" window in blogger not having a title field. I don't know why.

Anyhow, the real reason for the blog post: As of today, I'm done with my exams. Which makes me very happy, and will hopefully mean I will get around to blogging more often.

I think everybody should read FX's excellent post.

A few short notes on what's being reported:

It seems that after my previous speculation, a few unforeseen things happened:

• Apparently, my post, while partially incorrect, was somewhere close to the truth
• A third party accidentally posted full details on the issue, which corrected my mistakes. Shortly after posting these details, the post was pulled down again, but was archived by search engines (and those that had subscribed to the blog where it was posted).

There have been a number of slightly incorrect press reports which I'd like to clarify:

• I posted a partially incorrect, but close, guess on what the DNS issue might be. That is not the same as "publishing a reliable way to poison DNS". It is guessing how it might be done.
  
• I did not pull down any posts from my blog.
  

I do not think anything I have posted takes away from Dan's superb work on this issue. Some people are of the opinion that I "stole his thunder" for his Blackhat talk, and I disagree strongly: Dan's talk is a full hour on DNS, and all the interesting things within DNS. My post was a vague guess.

Imagine: A world-renowned particle physics expert decides to give a one-hour lecture in your hometown, and on your way there some guy on the street tells you "I think he will talk about (...30 seconds of physics here...)". Would you decide that listening to the physics expert talk is no longer necessary because the guy on the street told you everything ?

Also: Guessing how something is done knowing it can be done is easy. Dan did the hard part: Coming up with a clever attack in a protocol that is relied on everywhere. My guess doesn't come close to comparing to what Dan has done: He spotted something that everyone else missed beforehand. He also handled the entire situation with a lot of endurance, patience, and determination. We disagree on whether people have a right (or even duty) to discuss what the issue might be, but that doesn't mean that I do not have the greatest respect for Dan. And his talk will contain much more of interest than my silly 30 lines.

I think (German news site) Heise summed it up well:
"In fact, all of Dullien's hunches had already been sketched out the day that US-CERT published a vulnerability note on the security hole."

I guessed. I was close, perhabs closer than others, but no cigar.

On Dan's request for "no speculation please"

I know that Dan asked the public researchers to "not speculate publicly" about the vulnerability, in order to buy people time. This is a commendable goal. I respect Dans viewpoint, but I disagree that this buys anyone time (more on this below). I am fully in agreement with the entire way he handled the vulnerability (e.g. getting the vendors on board, getting the patches made and released, and I understand his decision not to disclose extra information) except the proposed "discussion blackout".

In a strange way, if nobody speculates publicly, we are pulling wool over the eyes of the general public, and ourselves. Consider the following:

Let's assume that the DNS problem is sufficiently complicated that an average person that has _some_ background in security, but little idea of protocols or DNS, would take N days to figure out what is problem is.
So clearly, the assumption behind the "discussion blackout" is that no evil person will figure it out before the end of the N days.

Let's say instead of having an average person with _some_ background in security, we have a particularly bright evil person. Perhaps someone whose income depends on phishing, and who is at the same time bright enough to build a reasonably complicated rootkit. This person is smart, and has a clear financial incentive to figure this out. I'd argue that it would take him N/4 days.

By asking the community not to publicly speculate, we make sure that we have no idea what N actually is. We are not buying anybody time, we are buying people a warm and fuzzy feeling.

It is imaginable that N is something like 4 days. We don't know, because there's no public speculation.

So in that case, we are giving people 29 days of "Thank us for buying you time.", when in fact we have bought them a false perception of having time. The actual time they have is N/4th, and we're just making sure they think that N/4th > 30. Which it might not be. It might be ... 1.

It all reminds me of a strange joke I was told last week. It's a russian joke that makes fun of the former east german government, so it might not be funny to everyone. I apologize up front: I am both german and a mathematician, so by definition the following can't be funny.

"Lenin travels with the train through Russia, and the train grinds to a halt. Engine failure. Lenin sends all workers in the factory that might be responsible to a labor camp.

Stalin travels with the train through Russia a few years later, and the train grinds to a halt. Engine failure. Stalin has all workers in the factory that might be responsible shot.

Honecker (the former head of State of the GDR) travels with the train through Russia. The train grinds to a halt. Engine failure. Honecker has a brilliant idea: "The people that are responsible should be forced to rock the train, so we can sit inside and feel like it is still running." "

It feels like we're all trying to rock the train.

If there was public speculation, we'd at least get a lower boundary on the "real" N, not the N we wish for.

So I will speculate.

The last weeks I was in the middle of preparing for an exam, so I really didn't have time to spend on the DNS flaw. I couldn't help myself though and spent a few minutes every other evening or so reading a DNS-for-dummies-text. I have done pretty much no protocol work in my life, so I have little hope for having gotten close to the truth.

As such, anyone with a clue will probably laugh at my naive ideas. Here's my speculation:

Mallory wants to poison DNS lookups on server ns.polya.com for the domain www.gmx.net. The nameserver
for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244.

Mallory begins to send bogus requests for www.ulam00001.com, www.ulam00002.com ... to ns.polya.com.
ns.polya.com doesn't have these requests cached, so it asks a root server "where can I find the .com NS?"
It then receives a referral to the .com NS. It asks the nameserver for .com where to find the nameserver for ulam00001.com, ulam00002.com etc.

Mallory spoofs referrals claiming to come from the .com nameserver to ns.polya.com. In these referrals, it says that the nameserver responsible for ulamYYYYY.com is a server called ns.gmx.net and that this server is located at 244.244.244.244. Also, the time to live of this referral is ... long ...

Now eventually, Mallory will get one such referral spoofed right, e.g. the TXID etc. will be guessed properly.

ns.polya.com will then cache that ns.gmx.net can be found at ... 244.244.244.244. Yay.

The above is almost certainly wrong. Can someone with more insight into DNS tell me why it won't work ?

*Blogspam*
Advanced Reverse Engineering Trainings Class

We still have a number of seats in our advanced RE class available. The class
will be held on the following three days:

1. Wednesday the 1st of October
2. Thursday the 2nd of October
3. Friday the 3rd of October

The class will be held in Frankfurt(Main) in Germany.
The class is limited to 17 students and will cover a lot of interesting ground. Amongst the things we will be teaching are:

• What a C++ compiler does and how to recognize these things in a binary:
• How to recover classes and inheritance,
• What templates will do in the binary
• Using the helping hand of MS RTTI to recover classnames and generate inheritance diagrams from the binary

• Getting the most out of the RE-DB SQL schema -- storing disassemblies in a uniform way in a database
• Differential debugging and isolation of security-critical features (e.g. "where in the world is the encryption code again ?")
• Crafting malicious input to reach target program locations
  
• Working on network infrastructure:
  
• Loading ROM images into IDA: IOS, Netscreen etc.
• Generic methods of identifying the base address
• Debugging IOS (and other network infrastructure) using BinNavi and the GDB protocol
  
• Using BinDiff to full advantage:
  
• Patch Diffing
• Porting comments & names
• Porting symbols of statically linked libraries (such as OpenSSL) back into your disassembly
  
• A reverse engineer's guide to static analysis:
• The reverse engineering intermediate language REIL
• Monotone frameworks, lattices, and fun things to do with them
• Lots and lots of fun things to do with Python
  

The class will be taught by me (Halvar Flake), Ero Carrera, and Felix 'Fx' Lindner.

The class will be held in a small Hotel called "Villa Orange" -- which has about 20 rooms, so usually the entire Hotel consists of reverse engineers.

For more info, visit
http://www.zynamics.com/index.php?page=trainings

Cheers,
Halvar
PS: It might be of interest to some readers that the Oktoberfest is from the 20th of September to the 5th of October this year -- this means you can either attend Octoberfest before or after the trainings class (although we recommend the latter).
*End of Blogspam*

Hey all,

> Supplemental note to Halvar & everybody else who has said, in effect, "this
> is why SSL was invented" -- there's more to internet security than the route
> from your computer to your online bank. Have you thought about what this
> bug implies for NTLM? Or every virgin OS installation on the planet? Or
> Google's entire business model?

just to clarify: I did not say this bug wasn't relevant, and I don't want my blog post to be construed
in that manner. What I did say was:

1. The average user always has to assume that his GW is owned, hence nothing changes for him. Specifically: He does not need to worry more than usual. Check SSL certificates, check host fingerprints. Don't use plaintext protocols.
2. For those providing DNS services, it is clearly preferrable to patch. A DNS system without trivial poisoning is preferrable to one with trivial poisoning.
3. In living memory, we have survived repeated Bind remote exploits, SSH remote exploits, a good number of OpenSSL remote exploits etc. -- I argue that the following inequality holds:
4. OpenSSL remote >= OpenSSH remote > Bind remote > easy DNS poisoning
5. I argue this because the left-hand side usually implies the right-hand side given some time & creativity.
   

The net has survived much worse.

So I guess summary is: Good find, definitely useful for an attacker, but we have survived much worse without a need for the great-vendor-coordination jazz.

Cheers,
Halvar
PS: I am aware that my sangfroid could be likened to a russian roulette player, that after winning 4 games concludes: "This game clearly isn't dangerous."
PPS: It seems that we will find many more critical issues in DNS over the next weeks - it's the first time in years that a significant quantity of people look at the protocol / implementations.