Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

January 12, 2019

Reversing C code … Radare2 part I

Filed under: Radare2,Reverse Engineering — Patrick Durusau @ 9:42 pm

Reversing C code in x64 systems with Radare2 part I by Pau Muñoz.

Starting with a very basic C program, Muñoz walks you through compiling the C program and then analyzing it with Radare2.

Interested to see where this series goes.

October 25, 2018

CVE-2018–8414: A Case Study in Responsible Disclosure

Filed under: Cybersecurity,Hacking,Reverse Engineering — Patrick Durusau @ 3:21 pm

CVE-2018–8414: A Case Study in Responsible Disclosure by Matt Nelson.

From the post:

The process of vulnerability disclosure can be riddled with frustrations, concerns about ethics, and communication failure. I have had tons of bugs go well. I have had tons of bugs go poorly.

I submit a lot of bugs, through both bounty programs (Bugcrowd/HackerOne) and direct reporting lines (Microsoft). I’m not here to discuss ethics. I’m not here to provide a solution to the great “vulnerability disclosure” debate. I am simply here to share one experience that really stood out to me, and I hope it causes some reflection on the reporting processes for all vendors going forward.

First, I’d like to give a little background on myself and my relationship with vulnerability research.

I’m not an experienced reverse engineer. I’m not a full-time developer. Do I know C/C++ well? No. I’m relatively new to the industry (3 years in). I give up my free time to do research and close my knowledge gaps. I don’t find crazy kernel memory leaks, rather, I find often overlooked user-mode logic bugs (DACL overwrite bugs, anyone?).

Most importantly, I do vulnerability research (VR) as a hobby in order to learn technical concepts I’m interested in that don’t necessarily apply directly to my day job. While limited, my experience in VR comes with the same pains that everyone else has.

I mention this as one data point in the submission of bug reports and as encouragement to engage in bug hunting, even if you aren’t a kernel geek.

If you follow the disclosure “ethics” described in this post, the “us” who benefits includes the CIA, NSA, Saudi Arabia, Israel, and a host of others.

August 3, 2018

Browser-based GDB frontend: gdbGUI [With cameo by Thomas Hobbes]

Filed under: .Net,Cybersecurity,gdb,Hacking,Programming,Reverse Engineering — Patrick Durusau @ 8:26 pm

Browser-based GDB frontend: gdbGUI

From the post:

A modern, browser-based frontend to gdb (gnu debugger). Add breakpoints, view stack traces, and more in C, C++, Go, and Rust! Simply run gdbgui from the terminal and a new tab will open in your browser.

Features:

  • Debug a different program in each tab (new gdb instance is spawned for each tab)
  • Set/remove breakpoints
  • View stack, threads
  • Switch frame on stack, switch between threads
  • Intuitively explore local variables when paused
  • Hover over variables in source code to view contents
  • Evaluate arbitrary expressions and plot their values over time
  • Explore an interactive tree view of your data structures
  • Jump back into the program’s state to continue debug unexpected faults (i.e. SEGFAULT)
  • Inspect memory in hex/character form
  • View all registers
  • Dropdown of files used to compile binary, with autocomplete functionality
  • Source code explorer with ability to jump to line
  • Show assembly next to source code, highlighting current instruction. Can also step through instructions.
  • Assembly is displayed if source code cannot be found
  • Notifications when new gdbgui updates are available

While cybersecurity is always relative, the more skills you have, the more secure you can be relative to other users. Or, as Thomas Hobbes observed in De Cive, revised edition, printed in 1760 at Amsterdam, bellum omnium contra omnes, “the war of all against all.” (The quote is found on pages 25-26 of this edition. The following image is from the revised edition, 1647.)

Look to your own security. It is always less valuable to others.

March 31, 2018

Reverse engineering the Notability file format

Filed under: Files,Reverse Engineering — Patrick Durusau @ 8:38 pm

Reverse engineering the Notability file format by Julia Evans.

From the post:

I spend a fair amount of time drawing comics about programming. (I have a new zine called “profiling & tracing with perf”! Early access is $10, if you want to read it today!)

So on Thursday, I bought an iPad + Apple Pencil, because the Apple Pencil is a very nice tool for drawing. I started using the Notability app for iPad, which seems pretty nice. But I had a problem: I have dozens of drawings already in the Android app I was using: Squid!

Notability does have a way to import PDFs, but they become read-only – you can draw on top of them, but you can’t edit them. That’s annoying!

Here’s the rough dialog that ensued:

I don’t use Apple products so I’m very unlikely to encounter Notability, with or without its limitations.

However, practice at reverse engineering a format? That’s a useful skill!

For non-Apple users, suggestions of a format to reverse engineer?

No promises but curious what looks interesting and useful.

PS: We should all be taking a chance on Evans’ new zine called “profiling & tracing with perf”. I will get paid soon so will report back on the zine.

January 30, 2018

Combating State of the Uniom Brain Damage – Malware Reversing – Burpsuite Keygen

Filed under: Cybersecurity,Hacking,Malware,Reverse Engineering — Patrick Durusau @ 5:43 pm

Malware Reversing – Burpsuite Keygen by @lkw.

From the post:

Some random new “user” called @the_heat_man posted some files on the forums multiple times (after being deleted by mods) caliming it was a keygen for burpsuite. Many members of these forums were suspicious of it being malware. I, along with @Leeky, @dtm, @Cry0l1t3 and @L0k1 (please let me know if I missed anyone) decided to reverse engineer it to see if it is. Surprisingly as well as containing a remote access trojan (RAT) it actually contains a working keygen. As such, for legal reasons I have not included a link to the original file.

The following is a writeup of the analysis of the RAT.

In the event you, friend or family member is accidentally exposed to the State of the Uniom speech night, permanent brain damage can be avoided by repeated exposure to intellectually challenging material. For an extended time period.

With that in mind, I mention Malware Reversing – Burpsuite Keygen.

Especially challenging if you aren’t familiar with reverse engineering but the extra work of understanding each step will exercise your brain that much harder.

How serious can the brain damage be?

A few tweets from Potus and multiple sources report Democratic Senators and Representatives extolling the FBI as a bulwark of democracy.

Really? The same FBI that infiltrated civil rights groups, anti-war protesters, 9/11 defense, Black Panthers, SCLC,, etc. That FBI? The same FBI that continues such activities to this very day?

A few tweets produce that level of brain dysfunction. Imagine the impact of 20 to 30 continuous minutes of exposure.

State of the Uniom is scheduled for 9 PM EST on 30 January 2018.

Readers are strongly advised to turn off all TVs and radios, to minimize the chances of accidental exposure to the State of the Uniom or repetition of the same. The New York Times will be streaming it live on its website. I have omitted that URL for your safety.

Safe activities include, reading a book, consensual sex, knitting, baking, board games and crossword puzzles, to name only a few. Best of luck to us all.

January 18, 2018

What Can Reverse Engineering Do For You?

Filed under: Cybersecurity,Reverse Engineering,Security — Patrick Durusau @ 9:18 pm

From the description:

Reverse engineering is a core skill in the information security space, but it doesn’t necessarily get the wide spread exposure that other skills do even though it can help you with your security challenges. We will talk about getting you quickly up and running with a reverse engineering starter pack and explore some interesting x86 assembly code patterns you may encounter in the wild. These patterns are essentially common malware evasion techniques that include packing, analysis evasion, shellcode execution, and crypto usages. It is not always easy recognizing when a technique is used. This talk will begin by defining the each technique as a pattern and then the approaches for reading or bypassing the evasion.

Technical keynote at Shellcon 2017 by Amanda Rousseau (@malwareunicorn).

Even if you’re not interested in reverse engineering, watch the video to see a true master describing their craft.

The “patterns” she speaks of are what I would call “subject identity” in a topic maps context.

January 11, 2018

Introduction to reverse engineering and Assembly (Suicidal Bricking by Ubuntu Servers)

Filed under: Assembly,Cybersecurity,Reverse Engineering,Security — Patrick Durusau @ 4:05 pm

Introduction to reverse engineering and Assembly by Youness Alaoui.

From the post:

Recently, I’ve finished reverse engineering the Intel FSP-S “entry” code, that is from the entry point (FspSiliconInit) all the way to the end of the function and all the subfunctions that it calls. This is only some initial foray into reverse engineering the FSP as a whole, but reverse engineering is something that takes a lot of time and effort. Today’s blog post is here to illustrate that, and to lay the foundations for understanding what I’ve done with the FSP code (in a future blog post).

Over the years, many people asked me to teach them what I do, or to explain to them how to reverse engineer assembly code in general. Sometimes I hear the infamous “How hard can it be?” catchphrase. Last week someone I was discussing with thought that the assembly language is just like a regular programming language, but in binary form—it’s easy to make that mistake if you’ve never seen what assembly is or looks like. Historically, I’ve always said that reverse engineering and ASM is “too complicated to explain” or that “If you need help to get started, then you won’t be able to finish it on your own” and various other vague responses—I often wanted to explain to others why I said things like that but I never found a way to do it. You see, when something is complex, it’s easy to say that it’s complex, but it’s much harder to explain to people why it’s complex.

I was lucky to recently stumble onto a little function while reverse engineering the Intel FSP, a function that was both simple and complex, where figuring out what it does was an interesting challenge that I can easily walk you through. This function wasn’t a difficult thing to understand, and by far, it’s not one of the hard or complex things to reverse engineer, but this one is “small and complex enough” that it’s a perfect example to explain, without writing an entire book or getting into the more complex aspects of reverse engineering. So today’s post serves as a “primer” guide to reverse engineering for all of those interested in the subject. It is a required read in order to understand the next blog posts I would be writing about the Intel FSP. Ready? Strap on your geek helmet and let’s get started!
… (emphasis in original)

Intel? Intel? I heard something recently about Intel chips. You? 😉

No, this won’t help you specifically with Spectre and Meltdown, but it’s a step in the direction of building such skills.

The Project Zero team at Google did not begin life with the skills necessary to discover Spectre and Meltdown.

It took 20 years for those vulnerabilities to be discovered.

What vulnerabilities await discovery by you?

PS: Word on the street is that Ubuntu 16.04 servers are committing suicide rather than run more slowly with patches for Meltdown and Spectre. Meltdown and Spectre Patches Bricking Ubuntu 16.04 Computers. The attribution of intention to Ubuntu servers may be a bit overdone but the bricking part is true.

November 13, 2015

Reverse Engineering Challenges

Filed under: Programming,Reverse Engineering,Software Engineering — Patrick Durusau @ 4:42 pm

Reverse Engineering Challenges by Dennis Yorichev.

After the challenge/exercise listing:

About the website

Well, “challenges” is a loud word, these are rather just exercises.

Some exercises were in my book for beginners, some were in my blog, and I eventually decided to keep them all in one single place like this website, so be it.

The source code of this website is also available at GitHub: https://github.com/dennis714/challenges.re. I would love to get any suggestions and notices about misspellings and typos.

Exercise numbers

There is no correlation between exercise number and hardness. Sorry: I add new exercises occasionally and I can’t use some fixed numbering system, so numbers are chaotic and has no meaning at all.

On the other hand, I can assure, exercise numbers will never change, so my readers can refer to them, and they are also referred from my book for beginners.

Duplicates

There are some pieces of code which are really does the same thing, but in different ways. Or maybe it is implemented for different architectures (x86 and Java VM/.NET). That’s OK.

A major resource for anyone interested in learning reverse engineering!

If you are in the job market, Dennis concludes with this advice:

How can I measure my performance?

  • As far as I can realize, If reverse engineer can solve most of these exercises, he is a hot target for head hunters (programming jobs in general).
  • Those who can solve from ¼ to ½ of all levels, perhaps, can freely apply for reverse engineering/malware analysts/vulnerability research job positions.
  • If you feel even first level is too hard for you, you may probably drop the idea to learn RE.

You have a target, the book and the exercises. The rest is up to you.

May 14, 2014

Reverse Engineering for Beginners

Filed under: Cybersecurity,Reverse Engineering — Patrick Durusau @ 8:57 am

Reverse Engineering for Beginners by Dennis Yurichev.

From the webpage:

Topics discussed: x86, ARM.

Topics touched: Oracle RDBMS, Itanium, copy-protection dongles, LD_PRELOAD, stack overflow, ELF, win32 PE file format, x86-64, critical sections, syscalls, TLS, position-independent code (PIC), profile-guided optimization, C++ STL, OpenMP, win32 SEH.

I guess I have a different definition of “beginner.”

Chapter 2 starts off with “Hello, World!” from C and by section 2.1.1:

Let’s compile it in MSVC 2010:

😉

At more than 600 pages this took a lot of work. I suspect that it will repay a lot of work with the text.

I first saw this in Nat Torkington’s Four short links: 13 May 2014.

July 1, 2012

The Case for Semantics-Based Methods in Reverse Engineering

Filed under: Reverse Engineering,Semantics — Patrick Durusau @ 4:47 pm

The Case for Semantics-Based Methods in Reverse Engineering by Rolf Rolles. (pdf – slides)

Jennifer Shockley quotes Rolf as saying:

“The goal of my RECON 2012 keynote speech was to introduce methods in academic program analysis and demonstrate — intuitively, without drawing too much on formalism — how they can be used to solve practical problems that are interesting to industrial researchers in the real world. Given that it was the keynote speech, and my goal of making the material as accessible as possible, I attempted to make my points with pictures instead of dense technical explanations.”

From his blog post: ‘RECON 2012 Keynote: The Case for Semantics-Based Methods in Reverse Engineering.’

Rolf also points to a reading list on program analysis.

Did someone say semantics? 😉

Anyone working on topic map based tools for reverse engineering?

Thinking that any improvement in sharing of results, even partial results, would improve response times.

Powered by WordPress