Can someone explain me why there is so few decent java decompilers out there ? Yes, JAD does a decent job in many cases, but sometimes simple control flow confuses it and the reconstruction is less than accurate. JODE is sometimes better in that regard, but fails on a good number of files, and also does not seem to assign new variable names based on the types of the variables.

With all that Java code on my cellphone, it's slightly annoying that it's so difficult to get a decent decompile. I mean, once I have that I can work in eclipse and refactor the class/variable names until I am happy.

Then again, it seems Java decompilers were all the rage in 1997-2002, and nowadays few people seem to be developing them...

I will be at Blackhat Federal in Washington DC next week, and since I am not giving a talk, I will have some free time to chat :-)

If anybody in the Washington DC area would like to meet and / or have our products demo'ed, please drop me a mail at halvar.flakeXnospamX@sabre-security.com.

Cheers,
Halvar

I would like to use this blog to make the MD5Sum and the SHA1sum of a certain file public:

MD5Sum:
5e5ed3b92b2abbcc1adaa18cc0ca6aaf

SHA1sum:
FFECBE21E3EC93A5AC2B94889AD2967881398A9C

Cheers,
Halvar

One of the most amusing new features of BinNavi in the v1.2 release is the GDB agent. FX (of SABRE Labs fame) worked hard to create a proxy that sits in-between BinNavi GUI and something speaking GDB serial protocol either via a serial line or via TCP.

Now, what is this good for ?

First of all, it allows one to use BinNavi's debugging capabilities on platforms that we do not explicitly support (if a recent GDB version works on it). This means most *NIX variants. Let's say, for some reason, you have a FreeBSD system on which you'd like to debug some piece of software, and BinNavi does not come with a FreeBSD debugger. But GDB runs on FreeBSD - so you just run your target under gdbserver and use the BinNavi GDB agent via TCP to transparently debug the target.

Now, using BinNavi on more-or-less arbitrary *NIX systems is nice, but the real joy lies elsewhere: FX made sure that the debugging proxy does not only speak the GDB protocol as spoken by GDB itself, but also the variants spoken by Cisco IOS and ScreenOS.

This makes reverse engineering embedded systems that speak either regular GDB protocol or one of the supported variants a blast: In the past, we had to proceed as follows:

1. Get a ROM image from somewhere
2. Stare at the image to figure out methods to decompress it properly
   
3. Once this was achieved, load the image into IDA and use switch()-constructs to determine the proper loading address of the image
4. Load the image into IDA again, this time at the correct address

Of course, live-debugging was usually out of the question.
With the BinNavi GDB Agent, we can now do the following:

1. Attach the device to a serial port and set it into GDB mode
2. Read & dump the memory from the current instruction pointer backwards until the device freezes
3. Read & dump the memory forwards from the current instruction pointer until the device freezes
4. Load the result into IDA and export the disassembly into BinNavi
5. Do live-debugging on the device in question :-)

So, as an exercise, we took a Netscreen-VPN5 we had acquired via Ebay. Unfortunately, it did not come with a support contract, so we could not get software images to disassembly. So we set the device into GDB mode by typing "set gdb enable" in the console, and connected:

C:\BinNavi.v1.2\gdbagent>gdbcmd COM1,9600 NS5XT
Connected via \\.\COM1 (baud=9600 parity=N data=8 stop=1) to Netscreen 5XT Agent
/ PowerPC
[q] quit | [r] Registers | [c] Continue | [R] Reset | [b] Breakpoint
[s] step | [m] Read Memory | [D] Detach | [d] Dump Memory Range

Reading Registers ... done
GPR0 = 1
GPR1 = 350f958
GPR2 = aecce8
GPR3 = ffffffffffffffff
GPR4 = 2e
GPR5 = 0
GPR6 = 0
GPR7 = 0
GPR8 = d55e70
GPR9 = ae0000
GPR10 = d50000
GPR11 = d50000
GPR12 = 40000024
GPR13 = 0
GPR14 = 0
GPR15 = 0
GPR16 = 0
GPR17 = 40140130
GPR18 = 0
GPR19 = 186ac40
GPR20 = 0
GPR21 = 350ff78
GPR22 = 186ac4e
GPR23 = ffffffffffffffff
GPR24 = 0
GPR25 = 0
GPR26 = 0
GPR27 = 0
GPR28 = 186ac40
GPR29 = 0
GPR30 = 186a910
GPR31 = ae5684
(...)
PC = 6826c
MSR = 29230
CR = 40000028
LR = 67c10
CTR = 249b30
XER = 20000002

The program counter is set to 0x6826c, and thus we know: Some code is mapped at 0x6826c. It is a pretty safe bet that all code will be consecutive in memory, sow we will now dump the memory forwards and backwards from this address: We type "d" in the command line and enter the base address and the number of bytes (in hex) we want to dump:

Memory at: 68000
Size: 400000
Filename: 0x68000.0x400000.dmp

The agent now begins to read the memory off the device in chunks of 1024 bytes via 9600 baud serial port - so it is a good idea to go to lunch in the meantime. Once we're back from lunch, we reboot the NS5XT - it will have hung when it ran out of memory to dump. We set it back into debugging mode and dump the memory before offset 0x68000:

Memory at: 40000
Size: 28000
Filename: 0x40000.0x28000.dmp

We stitch the two files together end-to-end, load them into IDA and run a few small scripts to identify function entry points and do some minor fixing of the disassembly (principally switch statements, and some function naming), and export everything into the BinNavi database. We then open it as usual in BinNavi, open the callgraph and start browsing around.

On the left, we see a callgraph view of the device's IKE packet handlers (which we inferred from string references in the disassembly), plus the functions that are directly called by them.

Now, which of these functions would be executed when we run a round of ike-scan against the device ?

Clicking on the red button makes BinNavi talk to the BinNavi GDB agent to set one-time breakpoints on all functions in the graph on the left - due to the serial link, this is not blazingly fast, but after seconds, not minutes, we have breakpoints on all these functions. We then run ike-scan against the device, and click on "stop recording" again. The result is the list of functions from our graph that were executed - highlighted in the following pictures:













Clearly we can do the same on the function flowgraph level in, for example, the function labeled IKE_SA_Handler above. Generally, everything you can do with BinNavi on Win32 executables you can also do with BinNavi on the embedded device now: Record traces, set breakpoints, set Python callbacks on breakpoints, read memory, read registers etc. etc...

The following three screenshots show the function in question being debugged. The first screen shows the path that is executed on running an ike-scan against the device highlighted in red. The second screen shows BinNavi having suspended the execution on the basic block with the red/blue border (the blue border indicates a persistent breakpoint on the basic block, the red border indicates that execution is currently suspended on that block). The third screen just shows the registers and some memory of the device at this point in time.

So to sum things up: With the BinNavi GDB Agent, you can debug anything that speaks the GDB protocol more or less just as if it were a regular windows app (small caveat: You are speaking with most embedded devices via a serial port, oftentimes 9600 baud. You probably do not want to set 60.000 breakpoints at once - aside from the bandwidth consumption, it is common for the gdb server to handle only a limited number of breakpoints. In our tests, setting several hundreds was no problem). Extracting ROM images in a format that is easily disassembled is easy, and full on-device debugging helps a lot with all our favourite tasks:

• understanding the code at hand
• identifzing which functions are responsible for which features
• hunting for security vulnerabilities
• constructing input to reach vulnerable locations
  

Have a good week, I have some more reversing to do :)

Oh, and be sure to check out Ero Carrera's Blog - he will post about the SQL database format used by BinNavi at the end of next week, and show why it's useful and flexible.

SP's blog has a good post today:

:-)

Over at the Matasano Blog :)

Matasano 's Blog quoted my post on Office bugs, and Ivan Arce made some excellent points in the comments:

1. 'They are inherently one-shot. You send a bad file, and while the user might try to open it multiple times, there is no way the attacker can try different values for anything in order to get control.”'

IA: OK. good point but…think about scale & diversity. Even in a targeted attack sending a one-shot client-side exploit against N desktop systems will with one hardcoded address will offset the value of ALSR with some probability of success for a given N. The attacker only needs ONE exploit instance to work in order to break into ONE desktop system, after that it is game over. Client-side bugs are one shot against the same system but not necesarrilly so against several systems in parallel.

Very true, I did overlook this. It also explains the use of really low-value phone-home bots as payload: If you're going to attack in such a "wide" manner, you essentially accept detection as long as you can compromise one of the relevant clients. This means that whatever you are sending will be lost, and therefore you won't send anything more sophisticated than a simple bot.

” 2. There can not be much pre-attack reconnaissance. Fingerprinting server versions is usually not terribly difficult (if time consuming), and usually one can narrow down the exact version (and most of the times the patch level) of a target before actually shooting valuable 0day down the wire. With client side bugs, it is a lot more difficult to know the exact version of a piece of software running on the other side - one probably has to get access to at least one document created by the target to get any data at all, and even this will usually be a rough guesstimate.”

IA: Hmmm not sure about this either. I would argue the desktop systems (clients) leak A LOT more information about themselves than servers and, generally, those leaks are much less controlled and/or controllable and easier to elicit than server leaks. After all, as a general principle, client apps are _designed_ to provide information about themselves.

Not to mention that a lot of information about your desktop systems has *already* leaked and is publicly available on the net now (server logs, emails, documents, stray packets, etc.), you just need to know how and where to look for it.

I disagree on this to an extent. My system leaks information about my mail client because I participate in public forums etc, but the majority of corporate users never gain any visibility outside of the internal network. Most people just don't use mailing lists or usenet etc. So it will be comparatively easy to attack some security officer (hey, I know his exact client version), but the CEO's secretary (which might be a lot more interesting as a target, and less likely to notice her computer is compromised) will be more or less "invisible".

Unbelievable but true

I am decompressing a bit after a few weeks of insane stress and thus I am actually reading blogs. And to my greatest surprise, I ended up reading this one. Now, Oracle security has never interested me ever since I tried to audit it in 2000 and it kept falling over without a fight (or without us really doing anything except sending a few letters to it), but I have to admit that Ms. Davidsons blog has a pretty high entertainment value (at least for me, a morallically degenerate piece of eurotrash full of the afterglow of a once good education system), AND it is refreshing to see someone with a bit of a classical education in IT security (I get picked upon regularly for the fact that I got my Latinum "on the cheap" and know jack shit about old greek - then again, my circle of friends includes a mathematician that claims that he can, by means of listening to a record, tell you in which church in france a certain piece of organ music was played, and hence I am always the loud and stupid one).

Anyhow, given Oracle's horrible code quality, I am very much positively surprised at the quality of Ms. Davidsons blog. And given what most people that have worked with static analysis tools before would describe as a horrible mistake in evaluating tool quality, I would like to mention that mathematics and geometry are part of a classical education. Whoever decided on the right source code analysis tool to use for detecting flaws in Oracle apparently failed that part.

Client Side Exploits, a lot of Office bugs and Vista

I have ranted before about careless use of 0day by seemingly chinese attackers, and I think I have finally understood why someone would use good and nice bugs in such a careless manner:

The bugs are going to expire soon. Or to continue using Dave Aitel's and my terminology: The fish are starting to smell.

ASLR is entering the mainstream with Vista, and while it won't stop any moderately-skilled-but-determined attacker from compromising a server, it will make client side exploits of MSOffice file format parsing bugs a lot harder.

Client-side bugs suffer from a range of difficulties:

1. They are inherently one-shot. You send a bad file, and while the user might try to open it multiple times, there is no way the attacker can try different values for anything in order to get control.
   
2. There can not be much pre-attack reconnaissance. Fingerprinting server versions is usually not terribly difficult (if time consuming), and usually one can narrow down the exact version (and most of the times the patch level) of a target before actually shooting valuable 0day down the wire. With client side bugs, it is a lot more difficult to know the exact version of a piece of software running on the other side - one probably has to get access to at least one document created by the target to get any data at all, and even this will usually be a rough guesstimate.
   

As a result of this, client-side bugs in MSOffice are approaching their expiration date. Not quickly, as most customers will not switch to Vista immediately, but they are showing the first brown spots, and will at some point start to smell.

So you're in a situation where you're sitting on heaps of 0day in MSOffice, which, contrary to Vista, was not the biggest (private sector) pentest ever (This sentence contains two inside jokes, and I hope that those who understand them aren't mad at me :-). What do you do with those that are going to be useless under ASLR ? Well, damn, just fire them somewhere, with some really silly phone-home-bots inside. If they bring back information, fine, if not, you have not actually lost much. The phone-home bots are cheap to develop (in contrast to a decent rootkit) and look amateurish enough as to not provoke your ambassador being yelled at.

If you are really lucky, you might actually get your opponent to devote time and resources to countermeasures against MS Office bugs, in the hope they don't realize that work will be taken care of elsewhere. In the meantime, you hone your skills in defeating ASLR through out-of-defined-memory-read-bugs (see some blog post in the next few days).

On a side note, I am terribly happy today. I've had more luck this week than I deserve.

While we're all talking about the next overflow and think that they have significance in the wider scheme of things, I'll climb on the soapbox for 5 minutes:

We should send peacekeeping troops to Darfour/Sudan. I was strongly opposed to the Iraq war (on the ground that invasion would bring civil war), but I plead my government: Take my taxes and send peacekeeping forces to Sudan. _If_ we have decided that the 'europeans-are-from-venus'-stance is obsolete, we have here a primary example of a conflict where external invasion appears necessary according to almost everybody (except the government in Kartoum).

While I am blogging about strange hobbies: I used to draw a lot, and still appreciate a few comics. Most importantly, local cult hero Jamiri.

Some examples:
http://www.spiegel.de/netzwelt/netzkultur/0,1518,grossbild-650193-422928,00.html

http://www.spiegel.de/netzwelt/netzkultur/0,1518,grossbild-669475-427889,00.html

I am known for odd hobbies and interests, and for a long while, I have been very fascinated with all forms of syncretism, specifically carribbean syncretism.

For various private reasons I am exposed to quite a bit of information about social anthropology, and I usually find the descriptions of odd rites in various societies very amusing and enlightening.

For example, any diagram of multi-family cross-cousin-marriage in some african societies just brings out the graph theory nerd in me, and serious scientific texts debating the difference between endo- and exocannibalism (eat your own tribe vs. eat the other tribe) are a fun diversion from reading dry stuff all day.

Yet I was unprepared for reading about the "Cargo Cult" today. And thinking about it, the sheer fact that a cargo cult developed in Melanesia makes me want to laugh and cry at the same time.

Read it. It's worth it.

Matasano refers to Bleichenbachers' recently published attack. Tremendously short comment:

Anything that does RSA with low exponent is likely attackable. And padding should always be OAEP. ;)

After all the Brouhaha surrounding the work on Apple wireless drivers, I'd like to pitch my two cents:

• Who cares wether this is real or not ? The possibility of breaking NIC drivers (especially in multithreaded kernels) is real, and nobody should be surprised if this happens. Has anyone ever disassembled the pos drivers that come with every cheap electronic USB gadget ? I have my doubts that the QA for NIC drivers is a lot better
• It seems we are not the only ones with a similar problem: http://eprint.iacr.org/2006/303.ps

In the above paper, Eric Filiol says he has broken E0, but does not give any description of the analysis - just a (significant) number of keys that lead to very long strings of zero's or to keystreams with a predefined hamming weight.

I am not decided on the paper yet - read it yesterday evening, jetlagged, over half a bottle of wine. This sort of publishing would be very easy for hash functions -- I would believe anyone that he can build secondary pre-images (or even pre-images) from MD5 if he can give me a string of input that hashes to "thequickbrownfox....".

Now, we just need stuff like that for bugs ;-)

Now with all this noise surrounding the ConsumerReports article where they created 5500 new virus variants, I would really like to get my hands on their sample list to see how VxClass, our malware classification engine, deals with them.

Just to clarify: PaiMei is really good, the previous post was not supposed to be negative or detrimental -- it's definitely cool stuff.

From Matasano:

"The results of one trace can be used to filter subsequent traces. This is huge (in fairness: it’s something that other people, notably Halvar [I believe], have been working on)."

I have to admit that our flash movies that we posted last year in September are mind-numbingly boring, but they do show this sort of stuff ;) -- BinNavi was able to record commentable debug traces since day 1.

http://www.sabre-security.com/products/BinNavi/flash_binnavi_debugger.html
http://www.sabre-security.com/products/BinNavi/flash.html

The entire idea of breakpointing on everything and doing differential debugging dates back to at least a Blackhat presentation in Vegas 2002. Fun stuff, and good to see that with PaiMei there is finally a free framework to do this.

I really need to re-do the BinNavi movies in the next weeks, they really do not do our product any justice any more.

To continue shamelessly plugging my product :-):

"Can I have stack traces for each hit? I know they’re somewhat redundant, but I can graph them to visualize control flow (in particular, to identify event and “parse” loops)."

You can in the next release (scheduled for October) where you can attach arbitrary python scripts to breakpoints and thus do anything to memory you want.

"Symbols. Pedram acknowledges this in his presentation. It didn’t slow me down much not to have them, but it feels weird."

If IDA has them, BinNavi has them.

"I need to be able to click on a hit and see the assembly for it (if there’s a way to click on something and have it pop up in IDA, so much the better)."

Right-click->open subfunction in BinNavi ;)

"Yeah, I need this for non-Windows targets. Remote debugging is apparently coming, which will help. I don’t imagine Pedram’s working on SPARC support (X86 and Win32 has eaten its way pretty thoroughly through the code). Also,"

We have Linux/ptrace support and a (very experimental) WinCE/ARM support.

I promise to redo the movies in the next weeks.

Enough of the advertisement crap.

Cheers,
Halvar

The security world never ceases to amaze me. A few years ago, a few friends of mine would run around security conferences and drunkenly yell "fuzz tester ! fuzz tester !" at people that, well, fuzzed. I found this really hilarious.

What I find amazing though is that fuzzers are now being seriously discussed in whitepapers and even called "artificial intelligence". Folks, can we please NOT do the time warp again ? And can we please start writing about something new ?

On a side note: Since I am a bit of a language nerd, I can't fail to notice that "artificial intelligence" takes a semantically cool twist when mentioned in the same sentence as "yellowcake from africa".

PS: This post is a rant about people that write about fuzzing as a new threat, not about people that write and use fuzzers. Just to clarify :)

I will have an 8-hour layover in Toronto tomorrow -- anyone up for a coffee ?

The article at this link is a bit funny, but if it is true that Materazzi made racial slurs against Zidane, then his headbutt was the ONLY proper answer to that.

Racism on the pitch should not be tolerated under any circumstances, and a healthy team would not tolerate racist remarks from any team member.

If Zidane's reaction was a response to racist remarks, then his headbutt is a symbol for a world cup that did not tolerate racism, and that united people from all over the world instead of dividing them.

On a side note, I am very happy for all the Italians :-) and I'd like to thank my Italian neighbours for having invited us to their place to watch the final.

Enough football, now back to work.

I know that I am going to draw the hate of many people for this post, but I refuse to think less of Zidane for the headbutt against Materazzi. As strange as it sounds, for some reason I am quite convinced that he must have had a good reason for this.

Nobody is mad enough to just headbutt an opponent in the worldcup finals in the last game of a legendary career unless he has a very good reason.

But well.