Wednesday, June 19, 2019

The First Facebook Libra Blockchain Explorer

As I was playing with the new Libra blockchain released by Facebook and friends yesterday I realized that there is no blockchain explorer available for Libra so I created one:
Currently it is slow, ugly, unstable and functionality is limited to viewing the latest TX or a specific account but it works and is useful to the developer community

I might add more features later if I feel like it. If you want to encourage me please send some testnet tokens to the account that shows in the browser or leave a comment here.

Friday, May 10, 2019

Adventures in WhatsApp DB — extracting messages from backups (with code examples)

Just a random piece I wrote on Medium describing the extraction process of conversations from WhatsApp and the analysis I did to do it. Just because I couldn't find free stuff about how to do this and every annoying free tool out there wants your credentials and full access to your data.

Medium post (paywall free link)
GitHub Repo

I might post some more random stuff soon. Or not...

Monday, October 14, 2013

Virtually Impossible @ ZeroNights & A PatchGuard Analysis on the company blog

Hi All,
I wanted to share two updates:
That's it for now...
G.D

Monday, June 11, 2012

Practical considerations implementing fuzzing acceleration via checkpointing

Hi all,
After giving my presentation in HITB I was fortunate to talk to some of the people that attended it and also some that contacted me via email afterwards. One of the most frequent questions I got was "how practical is it to implement a fuzzing acceleration framework?". Following up on that I decided to write a short post on the practical considerations of implementing an accelerated fuzzing framework by using DBI.
Some of the material in this post is based on one such Q&A discussion that I had with Peter Van Eeckhoutte (@corelanc0d3r) and published with his gracious permission.



Introduction to fuzzing acceleration via checkpointing

This section is aiming to provide a quick introduction to the subject. If you're familiar you can jump to the next section - practical implementation considerations.
If you're unfamiliar the concept of fuzzing acceleration via checkpointing and restoration the following slide from my HITB Amsterdam presentation provides an overview:




Friday, June 1, 2012

HITB Amsterdam 2012 Materials

Hi All!
HITB Amsterdam was an awesome conference. I hope you enjoyed it as much as I did. Thanks to all the organizers - you did an awesome job! Also thanks to everyone that attended my presentation you were a great audience, albeit sometimes quiet (shocked?!). :-)

Following HITB I wanted to make sure all of you know where to get the materials if you need those. The presentation is here, the source code for the pintool examples can be found here. If you are looking for more explanations of each of the code samples see this post.

Recently I've had a lot of discussions with people that attended the presentation in Amsterdam and with others regarding check-pointing techniques. Mostly for the sake of using check-pointing to perform high speed fuzzing but for various other usages as well. Since this seems like a topic that interests many people I've decided to write a blog post to detail some of the practical considerations implementing such systems. Look forward to this post soon.
If you'd like to request a post on a specific topic feel free to let me know what it is, though I make no promises...

Cheers!
G.D


Wednesday, May 23, 2012

Rebirth / Getting ready to HITB Amsterdam 2012

Hi all,
After a long period of not posting I'm finally back. A lot has happened in this period but most importantly I got married to my gorgeous wife Sonia. Due to the marriage preparations and some changes at work I didn't spare much time for personal research and publications. I currently have about five incomplete research projects. I am not going to make promises that I might not keep but I definitely plan to resume writing here and publishing new research in conferences.

I'll be giving a special edition of my instrumentation workshop in HITB Amsterdam on 24/May (known as a lab session in HITB speak). After learning a lot from the previous times I presented about instrumentation and improving my material I seriously believe that this will be the best edition ever. My only regret was that I had to cut down a lot of material due to the two hour presentation time. Normally people have trouble creating enough material for a two hour presentation so I guess I should count myself lucky. I've got a lot of goodness I want to put in and not enough time to talk about everything and show the demos.
Even so there is some awesome stuff included: automated vulnerability detection & prevention, fuzzing acceleration techniques, program visualization (good for anomaly detection and similarity detection), covert debugging (practically a built-in feature in PIN) and an introduction automated exploitation.

If you're interested in automated exploitation look forward to my next conference talk, possibly in hack.lu (if I'm ready by then). 

If you're attending HITB Amsterdam 2012 I hope you'll come listen. If not you're welcome to say "hi" (or share a beer) anytime - I'll be happy to meet anyone that reads what I write here.

Cheers,
Gal Diskin

Saturday, August 13, 2011

Post Vegas Post - BlackHat / DEF CON Workshop Materials, Notes and Some Mess

Hi All,
I've finally solved some internet access problems and can upload the materials I wrote for my BH and DEF CON workshops. For those in a hurry the materials are here: [presentation] [code examples]. If you want to catch me giving this workshop (in a somewhat modified version) come hear me in hack.lu.
BH & DC this year were great - great parties (except MS that initially didn't want to let me in until after the party started and I made other plans :P), some good talks and (re)meeting great people.
Thanks again to everyone that came to listen to me.

Some notes regarding these materials:
  • Please note that the presentation was not written with offline reading in mind so it might make a hard read in some places. Questions are welcome in the comments.
  • The Defcon presentation is mostly a variant of the BlackHat one (or vice versa) which is why I did not include both.
  • The examples might be included in the official Pin distribution some day. For now I'm going to start a page on this website to preserve these materials. If you have any submissions of updates, fixes or additional examples you want included send those to me. notifications of updates will be published via  twitter.
  • Since I was lazy and intended to control the length of my presentations by deciding what to include in the demos on the fly the details of the demos / examples mostly do not appear in the presentation itself. That is why I've included notes about the demos and examples below. Please note the examples were written with educational purposes in mind and not
  • The end of the presentation contains a ton of references to all sorts of DBI usages for security or whitepapers on the subject - highly recommended read for those interested in the field.
Examples and demos:
  • Exploiter1 - An example of automated exploit development for classic stack buffer overflows and assuming no DEP and ASLR. If you had it 5-7 years ago you could write a worm that would actually "multiply" and learn new attack vectors as it goes along (muhahaha :D). I'm intentionally releasing this degenerate version so as not to provide people that couldn't write this code alone with the ability. If you're interested in full capabilities along these lines - contact me privately, I'm considering it. I might write a longer blog post on this subject (if I ever get time to write).
  • InMemFuzz - An example of in memory fuzzing and of using checkpointing to accelerate fuzzing. please note the checkpointing part only covers registers. One of the exercises in the Defcon workshop was to complete it. Again, a blog post on this will be added to the fuzzing series if / when I have time.
  • RetAddrProtect - An implementation of "shadow stack" method to defend against return address overwrites in your program. I originally invented this method for some job back in early 2004 unknowing that the term "shadow stack" existed I called it "protection stack" and only very recently discovered the proper name for it which is why, since I'm lazy, the tool still calls it "protection stack". See the work from Caro'11 by MS guys on the matter (link in the presentation).
  • Taint 1-3 - Examples of basic taint analyzers. These are simple examples that only handle the propagation of taint through the MOV class of instructions. The first outputs some of the dataflow, the second improves the log to show only taint flow and the third adds tracking of the taint source.
    • Taint_vis_2D - is a script that is meant to show how a very simple (practically dumb) visualization of taint is still very useful to us compared to reading log files. Read the source to understand how it works.
  • Program data-flow visualization - Two examples of memory visualizations are included in the kit. Those are meant for working with a recording of all memory accesses generated by the "pinatrace" (memory access trace) example from the official Pin kit. When executed on the log file generated by pinatrace these tools generate a 3D view of the program memory accesses that allows us to analyze the program visually. For example, it is fairly easy to identify loops and extrapolate potential usages of those loops. To understand the information generated: one axis represents the address, the second represents the PC location at the time of the memory access and the third axis represents the order of the operations. Blue means a read, red means a write. You can navigate through the visualizations using the mouse (zoom in/out and rotate). Again, if you're interested in advanced taint / data-flow visualization capabilities I'm open to discussion privately. See example images below.
  • Anti Debug - the first anti debug example is meant to show that Pin will not trip this anti-debug protection while using a debugger would. The second is meant to show that the transparent debug feature in Pin allows you to debug ignoring Anti-Debug techniques. Please note that the first example will trip the debugger under the transparent debugger - if you want transparent debugging to work on it you need to write a pintool (which was meant as education / exercise).
  • Double Free - An example of how to detect potential double free cases. Some might say that it is less relevant due to the fact that is a fairly easy task using static analysis and modern libc protections however, sometimes you don't have the luxury of having access to the source code or you work on legacy systems where it becomes relevant. In addition, vulns like the OpenSSH double-free race condition vulnerability would not normally be caught by a static analyzer looking for double free.
  • Malloc Fault injection - this simple PinTool does exactly what the name suggests. It injects malloc failures into the program at a random interval. For our case I set the frequency to be very high (every ~100 calls to malloc) it is interesting to note that the Linux loader and libc initializations usually fail intelligbly with a reasonable message. 
  • VulnEx# - these are vulnerable code examples to run the tools on - each example purpose is documented.
Pretty Pictures:
Here are some pictures of visualizations with a small explanation on how to read those. these are based on the very early work of the OS loader in Linux while starting to execute "ls". If you're looking for why I choose this specifically the answer is "because" or in detail - because it fit me at that specific moment (yeah, I'm lazy).

Notice the series of memory read-writes a little up and to the right from the center - this is a loop, almost certainly with a counter. since no other memory writes are visible most probably this is a search loop or a loop related to register calculation

Same loop as before, now a little to the left from the center and depicted using separate lines for reads and writes. Note that it is now almost certain that the top red line represents some sort of counter.

On the center and a little below and to the right notice another loop - note the symmetry in the reads and writes relative positions. figuring out what it probably is is left as an exercise to the reader :P (you can also see this same loop from the top in the first picture to the left of the center)
~1000 memory accesses, note that blocks with relations are easily identifiable. Easy to see that a filtering capability is very valuable. finding more interesting patterns will require some more staring.

BTW, the ZIP files on google docs are downloadable - through "file" -> save original

-- The End (for today)
Please leave a comment and share if you liked it.

Posts or possibly talks or whitepapers in planning / phases of writing, though I don't know when I'll get to each particular item: "how I would go about blowing up batteries if I was 0xcharlie" (pending legal review - meaning it is too close to my work research and besides if batteries start blowing up there could be trouble...), "Fuzzing series part 2 - monitoring OR why I'm tired of hearing about !exploitable", "fuzzing series part 3 - fuzzing protocols from the RFCs using semi-context aware grammars", "how to attack HW using SW" (pending legal review - again close to work stuff), "Enough with the code coverage! - feedback driven fuzzing based on data coverage and taint analysis", "old/new heap attacks", "increasing exploit reliability". Every post or potential talk depends popular demand, free time and me not getting sued.

-- Gal