Our paper NTrace: Function Boundary Tracing for Windows on IA-32 from WCRE 2009 has now been published on computer.org:

Abstract:

For a long time, dynamic tracing has been an enabling technique for reverse engineering tools. Tracing can not only be used to record the control flow of a particular component such as a piece of malware itself, it is also a way to analyze the interactions of a component and their impact on the rest of the system. Unlike Unix-based systems, for which several dynamic tracing tools are available, Windows has been lacking appropriate tools. From a reverse engineering perspective, however, Windows may be considered the most relevant OS, particularly with respect to malware analysis. In this paper, we present NTrace, a dynamic tracing tool for the Windows kernel, drivers, system libraries, and applications that supports function boundary tracing. NTrace incorporates 2 novel approaches: (1) a way to integrate with Windows Structured Exception Handling and (2) a technique to instrument binary code on IA-32 architectures that is both safe and more efficient than DTrace.

http://www.computer.org/portal/web/csdl/doi/10.1109/WCRE.2009.12

If you do not feel like reading the paper, you can also take a look at the screencasts:

Part 1. Kernel Mode NTrace:
Tracing NTFS and the I/O manager

Part 2. User Mode NTrace:
Tracing COM loading a DLL

Reverse Engineering

My workflow for threat weighted hardware analsysis or research has changed with time. Slight uniformaty has found its way into my routine which is helpful for cross referencing knowledge between projects. With the curse of multitasking projects a constant this also reduces the time required to switch between projects or pickup on an old project. I’d like to share this with those that might have interest or comments for improvement. The organizational steps tend to reflect the actual structure I use for filing resources and data i gather. Note: this is for target/threat weighted research or analysis. This structure will probably not apply when the goal is weighted differently.

First, the directory structure:

• Attacks (segmented by attack class with logs on attempts and all information needed to replicate)
• Logs (all non-attack specific notes and logs)
• Photos
• References (datasheets, application notes, documentation)
• Reports (information used to document or report findings)
• Tools (software, schematics, non-attack specific custom built tools)

Workflow:

1. Objectives
   This isn’t represented as a directory but instead typically the first note sheet I start to write and store in the Logs directory. An objective comes from either a client or research goals. With clients this might come in the form of their general concern or attack vectors. For research this is often in the form of low hanging fruit (objective milestones).
2. References
   Build an overview of the device by determining the function and relation between components. Meaning, find all the datasheets or application notes you can, store them here and read them. I typically have a separate note sheet with very short summarization of this information which I store in the Logs directory.
3. Targets
   Again, not a directory. When I find a pin cluster I will test all the electrical characteristics (resistance to GND, voltage levels at different states, etc). I make note of these either on note sheets or visual notations and I store both in the Logs directory. electrical_10pinheader.txt, electrical_4pinpad.txt, electrical_3statebusctrl.txt, network_TCPIPstates.txt, firmware_interestingSymbols.txt, etc. This becomes extremely useful information not just for the current project but for cross referencing in future projects.
4. Attacks
   Make a sub directory for every class of attack (jtag, serial, i2c, spi, firmware, network, etc). If and when we have to build specific tools or record results, all of it will be here. In this case, for notes I store them with each attack, not in the Logs directory.
5. Reports
   When an attack is note worthy, be it a success or not, I will copy the relevent photos, notations, to this directory so that writing reports or documenting the work at the end is easier.

Additional repositories that are useful:

• Photos
  Take photos of everything. This is essential for documentation.
• Tools
  If I have to download software libraries, tools or schematics for building software or hardware tools I will store the originals here. If I write wind up writing custom code for e a specific attack ill store it in its attack directory (with dependencies here). Otherwise if it is a custom made tool used across many attacks I will store it here as well. Some of the tools I find useful eventually find their way into the sectk github.
• Logs
  All Notes or logs that do not relate to a specific attack go here. Such as general network captures, logic analysis logs, electrical testing notations, etc. At times I will go off on a general hunch that has no clear attack, target or objective and I will store the logs in a subdirectory. Also, any time I am working with software or a terminal (console) I keep a screen log (man screen) of the work and store and label these here as “screen_weekN_dayN.log”. I have one or two logs for every day while I am working on the project which gives me a very low level point to return to if I need to find something later that I might have forgotten to document. To retain absolute continuity of these logs I always append to the log for each day and when the log needs to be included in a directory for a specific attack I will copy it to that directory, retaining the original here.

Idealy all information should be digestable by one person. Verbose notes and documentation are essential for tracking down methods and pecularities later but ultimately you want to be able to quickly document the essentials either to pass on others, share with the community or include in a report to your client. I haven’t found a good medium between detail and summary in an active way so what I tend to do with my notes is repeat prior knowledge required to replicate findings, even if the information was already noted earlier in the same note sheet. The result is that when going back over notes one would start at the very end of the note sheet and work their way back up. Often times I will make note of this at the top of the sheet when I feel I have reached a closure point for the thread.

These are simple basic suggestions that are absolutely unexciting but often helpful. My experiance has been mostly with embedded analysis but this field can quickly forge into software level reverse engineering so this structure can be applied to some degree there as well. I would be elated if anyone has constructive suggestions or would like to contribute link or comment on their own workflow.

By: PKKH

A lot can be achieved in two and a half decades. For an individual, its roughly one-third of the average lifespan. For a nation, its enough time for an entire generation to come through. A nation can be transformed from a marshy swamp into one of the largest economies of the world – as in the case of Singapore.

What did Indian Air Force (IAF) achieve in twenty six years while consuming over $2 billion? the answer to that is Zilch; Zero; Nada; Nothing – except a failed project and a continued embarrassment in the shape ‘Tejas’. Tejas LCA (Light Combat Aircraft, also known as Last Chance Aircraft) has gone many trials and tests and there’s no sign of induction as yet. It has now been announced to enter IAF in 2010.

Pakistan’s own ambitious JF-17 project was launched in partnership with China in 1995. In just eleven years and with just $500 million spent, the JF-17 was flying in Pakistani Airspace on March 23rd 2007 – with the maiden flight having taken place much earlier in 2003.

The Indian Air Force on the other hand has with significant assistance from France, Israel, and the United States worked on the Tejas (meaning Radiant) LCA project for over two decades and the aircraft is no closer to induction. Infact it gets worse; the unit cost of one JF-17 is $15 million dollars, while a Tejas will cost up to $31 million – which is closer to the far advanced Russian Su-30’s starting cost ($33 million). India would be well advised to buy more of the Russian aircraft instead of wasting billions of dollars in trying to produce its own ‘indigenous’ fighter plane.

In 1983, IAF launched a Light Combat Aircraft (LCA) program to replace its flying coffins, the MiG-21’s. Earlier in 1981, a study was conducted by IAF, the ‘Long Term Re-Equipment Plan’, to make plans for a future aircraft that would not only replace MiG-21’s but also be cheaper option to foreign imported planes. The Indian government created an entire agency to manage the LCA Tejas program. Tejas was to be developed by Hindustan Aeronautics Limited (HAL), but Aeronautical Development Agency (ADA) was the managing agency of the program.

To develop Tejas, India sought help from Israel and France. The IAF’s Air Staff Requirement for the LCA would not be finalized until October 1985. So, for the first four years, Indian authorities failed to even come up with personnel list who would work on the project. Initially Indian authorities believed they would be able to do a test flight in 1990, and have Tejas induction ceremony in 1995. You would think that 12 years would be enough to produce a fighter plane – however thanks to India’s utter incompetence, Tejas is still waiting to be inducted into IAF as of October 2009.

In 1990 HAL started work on the technology demonstrators but because of the financial crunch in India, full-scale funding was not authorized until April 1993. First technology demonstrator, TD-1, was rolled out in Nov 1995 and was followed by demonstrator 2 in 1998, but they were kept grounded for several years due to structural concerns and trouble with the development of the flight control system. (http://www.aerospaceweb.org/aircraft/fighter/lca/).

The Indian engineers wanted to develop a fly-by-wire system of its own. This is no easy task and requires extensive knowledge of flight control laws and the expensive writing of a considerable amount of software code for the flight control computers, as well as its integration with the avionics and other electronic systems. India tried but failed. With no other option left, India sought help from British Aerospace and Lock Heed Martin for its ‘indigenous’ project, who in turn obliged in 1993.

Until 1998 when India, in an attempt to flex its muscles conducted meaningless nuclear tests which have recently been revealed to have been complete failures, Lockheed Martin was helping India’s failing Tejas project by providing a series of in-flight simulation tests of the integrated flight control software which were conducted on F-16 VISTA until July 1998.

For the Multi-Mode Radar (MMR) of Tejas, India turned to Ericsson, and Ferranti Defense Systems, who make such radars. The Indian engineers disgracefully decided to copy those radars and call it indigenous production. As of 2002, the development of MMR was experiencing major delays and costs escalation. It took India four years just to figure out the problem with the radar. Test results in May 2006 proved that the there was a compatibility issue between radar and the advanced signal processor module. The Indians would be well advised to learn from China – the undisputed champions of reverse engineering – before its own botched and expensive attempts.

India also signed a deal with Rafael of Israel to supply Laser pods, and Sextant of France and Elbit of Israel to supply multi-function displays. Despite all these failures, the Indian authorities still believed they produce the engine on their own. Initially it was decided to equip Tejas with the General Electric F404-GE-F2J3 engine. In 1986, a parallel program was developed to produce an indigenous engine. It was named, Kaveri, but India overconfidence while trying to reverse engineer only managed to ensure the production was slowed because of technical difficulties – followed by the 2004 test of the engine that was a complete failure.

In the end India had to turn to French aircraft company Snecma for technical assistance. The height of India’s false ego and attempts at saving face is evident from them naming the French engine that will be used in Tejas, as Kaveri. On the other hand, the GE engine is still being procured for use in Tejas planes that are going to be produced for induction into IAF. The engine trouble didn’t end there, in 2008 it was announced that Kaveri, is not ready for Tejas, and India announced, in May 2009, a tender for $750 million for more powerful GE engine or Eurojet EJ200 engine. (http://www.hinduonnet.com/fline/fl1802/18020420.htm)

As a result of all this rambling the unit cost of Tejas has jumped from $21 million to $30 million. The first batch of Tejas is scheduled to be inducted in IAF in 2010, and will be combat ready in 2012 – or so they say. By 2012, PAF will have at least 60 JF-17’s combat ready fully equipped and prepped up.

The JF-17 Thunder – a joint project between Pakistan and China – was riginally designed to be a small and capable lightweight fighter powered by a single engine to reduce costs – the JF-17 was supposed to be a simple and inexpensive solution for replacing large fleets of obsolete types in the air forces of developing countries. The JF-17 evolved into a more advanced fighter during the later stages of development with revised terms of reference by the Pakistan Air Force and the incorporation of more modern features and technologies.

Being simultaneously manufactured in Pakistan and China, ten JF-17’s have already been inducted in PAF. The Pakistan Air Force plans to make the first JF-17 squadron officially operational by the end of 2009.

Apart from smaller Air Forces, Egyptian and Iranian Air forces have confirmed interest in purchasing these aircraft from Pakistan.
The JF-17 Thunder project has been completed in a record period of four years. China National Aviation Corp officially signed the development contract for the FC-1 airplane in 1999. The project initially suffered a setback due to imposition of sanctions in 1999, which hindered acquisition of avionics and weaponry for the aircraft. The avionics had to be delinked from airframe development in 2001. China National Aviation Corp completes the detailed preliminary design in 2001 and in 2002 the company completed the detailed design structure and the system charts.

On 25 August 2003 the “owlet dragon” FC-1 airplane carried on the initial flight. It flew 17 minutes before it returned to the airport.
The aircraft was intended to be a match for the Indian Light Combat Aircraft (LCA), which is (despite all setbacks) still expected to form the backbone of the Indian Air Force in future. There are, however, some features like advanced and futuristic avionics and cost effectiveness that give the JF-17 an edge over the LC – apart from the fact that it is actually ready and being inducted in the Pakistan Air Force, compared to its Indian counterpart which may take many years, if it is ever finished. There are rumors within official circles in India that a proposal to purchase the 60 JF-17 aircrafts from Pakistan was actually drafted before being vetoed by Air Chief Marshal Pradeep Vasant Naik after the attacks in Mumbai.

SPECIFICATIONS OF THE JF-17 and TEJAS LCA

Click to Enlarge

JF-17 – Specifications

Role: Multi-role combat aircraft.
Manufacturer: Pakistan Aeronautical Complex.
First flight: 25 August 2003.
Introduced: 12 March 2007.
Status: Under serial production and in active service.
Primary user: Pakistan Air Force.
Produced: In Pakistan: January 2008.
Unit cost: US$20 million (estimated).

General characteristics

Crew: 1
Length: 14.0 m
Wingspan: 9.45 m (including 2 wingtip missiles)
Height: 4.77 m
Wing area: 24.4 m²
Empty weight: 6,411 kg
Loaded weight: 9,100 kg (including 2× wing-tip mounted air-to-air missiles)
Max takeoff weight: 12,700 kg
Power plant: 1× Klimov RD-93 turbofan
Dry thrust: 49.4 kN
Thrust with afterburner: 84.4 kN
G-limit: +8.5 g
Internal Fuel Capacity: 2300 kg

Performance

Maximum speed: Mach 1.8
Combat radius: 1,352 km
Ferry range: 3,000 km
Service ceiling: 16,700 m
Thrust/weight: 0.99

Armament

Guns: 1× 23mm internal GSh-23-2 twin-barrel cannon.
Hard points: 7 in total (4× under-wing, 2× wing-tip, 1× under-fuselage) with a capacity of 3,629 kg (8,000 lb) external fuel and ordnance.

Rockets: 57mm/90mm unguided rocket pods.
Missiles: Air-to-air missiles: PL-5E, PL-9C, PL-12 / SD-10.
Air-to-surface missiles: anti-radiation missiles; anti-ship missiles (AM-39 Exocet); cruise missiles (Ra’ad ALCM).

Bombs: Gravity/Unguided bombs: general purpose (Mk-82, Mk-84); anti-runway (Matra Durandal), Precision guided munitions: laser-guided (GBU-10, GBU-12, LT-2); satellite-guided, Cluster bombs: anti-armour (CBU-100/Mk-20 Rockeye).

Others: Up to 3 external fuel drop-tanks (1× under-fuselage 800 liters, 2× under-wing 800/1100 liters each) for extended range/loitering time, Externally mounted avionics pods for EW, ECM, ELINT, FLIR and targeting, BM/KG300G self-protection jamming (ECM) pod, KZ900 electronic reconnaissance (SIGINT) pod, Blue Sky navigation/attack pod, FILAT (Forward-looking Infra-red Laser Attack Targeting) pod.

Avionics: NRIET KLJ-7 multi-mode fire-control radar.

Production: 10 aircraft already inducted. First full batch manufactured in Pakistan to be inducted by end of the year.  30 planes will be manufactured at Pakistan Aeronautical Complex every year.

JF-17 Planned upgrades: all PAF JF-17 jets will be modified to aerial refueling capable; Subsequent upgrades will be made on PAF JF-17 jets approximately every five years.

PAF JF-17 Order: Pakistan Air force will produce total 350 JF-17 jets excluding export.

The Indian Air Force Tejas LCA

Tejas – Specifications

Role: Multi-role fighter.
Manufacturer: Hindustan Aeronautics Limited.
First flight: 4 January 2001.
Introduction: 2011.
Status: Under development / pre-production.
Primary user: Indian Air force.
Unit cost: US$20 million (estimated).

General characteristics

Crew: 1
Length: 13.20 m
Wingspan: 8.20 m
Height: 4.40 m
Wing area: 38.4 m²
Empty weight: 6,500 kg
Loaded weight: 9,500 kg
Max takeoff weight: 14,500 kg
Power plant: 1× General Electric F404-GE-IN20 turbofan
Dry thrust: 53.9 kN
Thrust with afterburner: 85 kN
G limits: +8.5 g
Internal fuel capacity: 3000 liters

Performance

Maximum speed: Mach 2.0
Range: 3000 km
Service ceiling: 15,950+ m
Thrust/weight: 1.02

Armament
Guns: 1× mounted 23 mm twin-barrel GSh-23 cannon.
Hard points: 8 total: 1× beneath the port-side intake trunk, 6× under-wing, and 1× under-fuselage with a capacity of >4000 kg external fuel and ordnance.

Missiles: air-to-air missiles: Astra BVRAAM, Vympel R-77, Vympel R-73.
Air-to-surface missiles: Kh-59ME TV guided standoff Missile; Kh-59MK Laser guided standoff Missile, Anti-ship missile, Kh-35, Kh-31.
Bombs: KAB-1500L laser guided bombs, FAB-500T dumb bombs, OFAB-250-270 dumb bombs, OFAB-100-120 dumb bombs, RBK-500 cluster bombs.
Others: External fuel capacity: 5×800 liter tanks or 3×1,200 liter tanks, totaling 4,000/3,600 liters.

Avionics: EL/M-2052 AESA radar.

Production: Still in pre-production.

IAF orders: Indian Air force will get total 220 Tejas jets (Expected)

http://evilcodecave.blogspot.com/2009/11/crimeware-researches-about-eleonore.html

Direct Dimension에서 작업한 결과물…

This is a case study of a project we did to scan a vintage Jeep undercarriage frame. It was completely ’shot’, rusted and distorted. The purpose was for the car club to re-manufacture new Jeep frames. So besides scanning it, we also reverse engineered it into an accurate CAD model as if it were brand new. This presentation walks you thru the process, the tools & software we used, and some of the behind the scenes look at reverse engineering into solid CAD models.

So perhaps you’re standing at this point in your life where you feel like you’re at a turning point.  You don’t know what the turning point is exactly, but you know that something should change.  Maybe you’re wondering about a new job, a new hobby, a new interest, a romantic relationship, or religion.

Let me suggest that the change you need is not a hobby, a new love life, or religion.  You need a comprehensive meta-narrative–that is, a story that is able to encompass your story and make sense of life.  You need a worldview that is able to explain everything you encounter, and bring you through it successfully.  You need a person, a perfect, wise, all-powerful, all-knowing person who will go with you through life day by day, moment by moment.  There’s only one person who can do that: Jesus.

The reason you may have a barrier between yourself and Jesus is simple: Sin.  Sin keeps all of us from Jesus, whether we call ourselves Christians or not.  Jesus once told us to “be perfect as your heavenly father is perfect.”  God is a just God who demands perfection.  In other words, if you aren’t perfect, you aren’t good enough to be a son or daughter of God.  That’s his standard.  Are you perfect?  No, I didn’t think so.  So what do you do?

There’s not much you can do on your own.  You can’t get to being perfect on your own.  So God wants to adopt you as a son or daughter, but he can’t do that unless you’re perfect.  Enter Jesus.  Jesus is already God’s son.  He’s perfect.  He’s God himself.  The solution: get punished on your behalf.  Die on your behalf.  Suffer the consequences of sin on your behalf.  And when he does that, you are forgiven of all your sins and receive from Jesus his perfect righteousness.  So God sees you as perfect.  As a result, the Holy Spirit becomes your bestest, closest, most intimate buddy.  He moves in and fills you with the thinking and feeling of Jesus for the rest of your life.  You enjoy the close, father-child relationship with God that Jesus enjoys.  You get the wisdom of an all-knowing God at your disposal.  God guides you through the mine-field of life and through your simply daily concerns.

All you have to do is believe what I’ve told you.  Believe and tell Jesus that you believe he died for your sins and rose again….oh yeah, I better not leave that part out.  He rose again.  The point is, he beat death.  He destroyed it.  He isn’t dead anymore, and he never will be dead again.  That means those of us who follow Jesus will never be dead.  Sure, we’ll die on earth and get buried, but immediately following that is the experience of being perfect, sinless, and with God forever in heaven.  That’s a guarantee.

What’s this have to do with Reverse Engineering your life?  Honestly, you can only plan so much.  You need the help of the chief architect.  You need a God who will tell you things like: here’s what I made you to do.  Here’s your special gifts, stuff I’ve designed you for.  You’ll really like doing this job.  You’ll love having this many kids….

You can’t tell the future.  But God is already there.

So maybe you read this and you’re thinking, “Chaplain Dre, you’re just giving me religion again!”  Nah.  Not a religion.  I define religion as a system of philosophy that tells you what to do and what not to do, and as long as you do those things and don’t do the other things, God will like you.  This is a relationship.  This is a father relating to his sons and daughters.  You can’t do anything to lose his love.  Once you believe and follow Jesus, and become adopted by God, you will always have his acceptance and love.  No way you can do anything to lose his favor.

So why do we even follow the Bible or do good things?  Because that’s what God’s kids do!  We follow Jesus and do the good things and avoid the bad things because the Christian life changes our hearts.  We begin to want to do good deeds and avoid evil deeds.  It’s what we want to do.  It’s how we get enjoyment and fulfilment and pleasure in life.

It’s that simple.

Get this piece in place first.  What is your worldview?  Is it a politic, a religion, a philosophy?  Or is it a person who can really make a difference in life.  Before you begin reverse engineering your life, put this piece in place.  It’s the cornerstone for everything else.

Feel free to write or call me.

Chaplain Dre

My day has both sucked and blown … as a result, I have had such dreadful potty-mouth that the Parliament of Scotland called to advise me that I’ve been declared an outpost of Billy Connolly … so I will make myself feel better by thinking about writing.

And the thing I’ve been thinking about is the tool of reverse engineering. I’ve gone back over the notes I took from the superb Alison Goodman[i] (she of Two Pearls of Wisdom http://www.alisongoodman.com.au/ and an exquisite Meerkat impersonation). When I say ‘took’, I don’t mean I beat her up and threatened her with bad grammar – I mean she talked, I listened politely and took notes in the manner of a scribe. Of course, now that I try to read my handwriting (which bears a striking resemblance to hieroglyphs written by drunk chickens) I think perhaps I would have been better off beating Alison up and taking her notes.[ii]

Where was I? Ah, yes. Reverse engineering.

Now the thing about this technique is that you start at the end – hence, the reverse part. It’s about examining where your story’s finished up and then working backwards to check the causal links that are holding the narrative together. Confused? So I am most of the time; you’ll get used to it[iii].

You can do this at Act level or Scene level – even paragraph level if you’re bored. Let’s say you’ve finished Act One, so now ask yourself ‘What happens at the end? What point have you been making your way towards? What is the final effect of the Act?’ (Alison’s example was ‘Palace explodes’ – which is admirable. I think if you’re working towards something, it should always be about something the size of an exploding palace.)

Once you’ve established that, ask ‘What caused that moment? What led to it?’ And keep working backwards – ‘What caused the moment before that one?’

And so on and so forth.

This is a great way to examine the causal links in your plot, to look at what is propelling your action forward. If you cannot see a causal link or a logical series of causal links leading back from your climax at the end of the Act, then you need to go back and plug the holes.

This is also a useful way to check the emotional beats that lead to a climax – what are the causal effects of the build up. Do they make sense?  Are the choices and actions of your characters reasonable in the circumstances? Another thing to ask yourself is this: is the reader going to care/be emotionally engaged? Will they stick with your story right up to the revelation or will they throw the book aside, snorting “No one does that!”

Reverse engineering can also show up where things are just too easy or too coincidental for your story. You need to make your characters work hard, you need to make them suffer. Convenient fixes for problems are unsatisfying – if every obstacle can be fixed by the application of magic which is easily available to everyone ( the old ‘if everyone’s special then no one’s special’ rule[iv]) then why bother? Readers want to see conflict, they want to see suffering before triumph – that’s what makes the character’s – and the reader’s – journey worth something.

This technique looks not at the big picture but at the fine details (the Devil being in them) and this is a way of finding where the cracks are in the walls of your novel house (or indeed your short story apartment). I applied it to a short story recently and worked out where things were going wrong – I hadn’t documented the emotional journey of a secondary character and her development was essential to understanding that of the main character. Looking backwards at the causal links meant I was able to see where I’d been and where I’d missed steps.

[ii] A lesson for next time.

[iii] See? Still got the crankies. Gonna take a really big choclit patch to cure this.

[iv] See previous post on On The Limits of Magic http://angelaslatter.com/2009/07/23/on-the-limits-of-magic-or-if-everyone%E2%80%99s-special-then-no-one%E2%80%99s-special/.

I’ll be tearing down the basics of unlocking a baseband along with a few examples (My “examples” are iPhone related baseband hacks) I.E What’s needed and how it’s used.

Now first of all, this completely legal, safe, and not “wrong” in anyway, as the proof lies in the DMCA. You should read it, it’s a nice set of copyright laws..

This is Reverse Engineering. Anyone can learn it. C++ along with some ARM Assembly and perhaps a little cryptography (which I personally think is a pain in the butt to learn and have completely abandoned it) should get you started.

First things first, you need an
exploitable crash. An exploit we need here is some sort of crash that leads to a buffer overflow. A buffer overflow wil allow you to execute unsigned code (basically whatever you want).The overflow is used as the injection vector since we can inject our own code into the baseband bootrom. In this case, we want a payload to be run. A payload will take advantage of the exploit and put it to good use. Write up a decent payload and perhaps a nice little GUI to go along with it, and you’ve got yourself an unlock! Yay!

Now let’s take a look at an example. Since the iPhone is a big part of unlocking and 3rd party applications, let’s use that. Back on the 3.0 firmware, the iPhone baseband was numbered 04.26.08. That baseband had an AT+ command that was able to fully crash the baseband. Now, you know you have a crashed baseband when you see something like this from your terminal screen:

AT
OK
AT
OK
AT
OK
AT
OK

The command just so happened to contain a buffer overflow, so basically the crash was used as the injection vector. A payload was written (codenamed ultrasn0w by the iPhone Dev Team) and the unlock was made.

Now you have to be careful with an unlock. Finding a permanent one is NOT easy. You should have a timing impact to think about the better time to release it. I.E When the next software update or hardware update becomes available.

So there’s my example. I’ll probably do a post about executing unsigned code on the bootrom. But for now, there’s my Baseband teardown.

Check out this epic battle between man and I2C EEPROM. Devin wanted to fix a bug in the Linux driver for his HVR-1600 TV tuner card. He suspected that the Linux driver didn’t configure the board correctly, so he sniffed the I2C-based configuration traffic under Windows with a Saleae Logic. There’s a great overview of his process, including identifying test points, using them, and  filtering the traffic with a Perl script.

This showed up in our referrers list because of a link in a comment, so all thanks go to andrea venturi for this tip!

Updated, forgot the link.

I recently read Christian Wojner’s excellent paper on Mass Malware Analysis and it re-ignited my desire to build an automated environment to improve and speed up my current malware analysis capabilities. The paper details a step by step for duplicating Wojner’s environment, but I as I don’t have any spare equipment I’ve been looking for alternative routes.

Fortunately the paper also explains the theory, thought process and design of the system so that the reader can modify to suit their own requirements. To achieve this I’ve been trying replace the Xubuntu and Virtual Box host with my existing  ESXi environment detailed in previous posts.

With a bit of Googling the vSphere CLI became the obvious choice to replace the control component for the infected machine in the automated malware environment. vmware-cmd.pl provides the functionality to both stop/start virtual guests and to revert the guest to previous snapshots, exactly what is needed for the malware analysis environment. The commands to be utilised would be (– is a double dash):

vmware-cmd.pl –server <ESXi Host> –username <user> –password <pass> /path/to/guest.vmx getstate

vmware-cmd.pl –server <ESXi Host> –username <user> –password <pass> /path/to/guest.vmx start

vmware-cmd.pl –server <ESXi Host> –username <user> –password <pass> /path/to/guest.vmx stop

vmware-cmd.pl –server <ESXi Host> –username <user> –password <pass> /path/to/guest.vmx revertsnapshot

This should have been enough to adapt Wojner’s control scripts to use ESXi instead of Virtual box, but it appears that for the first time I’ve encountered a crippled feature not available in the VMware’s free offering. Running the stop/start/revert commands results in the below exception:

Fault:
SOAP Fault:
———–
Fault string: fault.RestrictedVersion.summary
Fault detail: RestrictedVersionFault

So that’s that, unless I happen to win the lottery (which I don’t play) or someone is able and willing to provide a full ESX license to a struggling researcher (which I don’t expect to happen) I’m back to looking for a replacement Wojner’s VirtualBox control process. On with the next…

– Andrew Waite

I have been doing Yellow Ribbon reintegration briefings for the 81st Infantry this month. One of the main themes I have been emphasizing is the concept of reverse engineering your life. The idea is that we should set a long- range goal for our personal lives and families 30-50 years down the road from now.  We then work backward, laying out the necessary stages in life to accomplish the goals.  In this way, deployment and the stress of reintegration become an opportunity to re-evaluate life and start creating a “new normal” for daily living.

This is the first post in a series I plan to do on reverse engineering your life.

Worldview

Before one can determine goals, plans, or even dreams, I believe one needs to resolve the question of worldview. Your worldview is your perspective and understanding of the world around you. It encompasses your understanding of life, the universe, and everything (yes, that’s a Hitchiker’s Guide reference for you sci-fi fans).  Your worldview affects your understanding of politics, your neighbors, and the news. It determines your major and minor decisions.  Your worldview determines your morality and explains who you are in relation to God, family, and others.  Where you choose to work, who you marry, and how you raise your kids are all affected by your worldview.

I do not mean religion.  A religion, as I understand it, is a list of do’s and don’ts that promise to earn you favor with God.  A worldview moves beyond that sort of living.  It is a perspective, a complete system of understanding for life.  Now, most people do not operate under a comprehensive worldview.  It is common to have a religion to explain God and morality that has no say in how one chooses a mate.  You may follow your desires when it comes to selecting a movie to rent, with no regard to how it fits into you larger worldview.  For the most part, we live fragmented lives which display little coherence.  Before you can really begin putting together a reverse-engineered life, it is necessary to have a coherent, comprehensive worldview.  You can’t determine a general path into the future if you don’t have guidance in what that future should look like.  It’s one thing to have dreams, but if you realize your dreams someday, will you be fulfilled?  Will you be satisfied?  Or will you find the accomplishment empty?

The problem is that there is way too much in life to take into account through any single system.  Even Christianity as a system is unable to encompass all of life. Christianity has little in and of itself to say about choosing a doctor, designing a skyscraper, determining an MOS, fixing your car, or going to the game.  It simply doesn’t cover all that.  And when you consider all the world systems and religions, you find that no one has created a system which can be this comprehensive.  Truly, such a system must be so large that it would have to be the result of knowing everything and being everywhere at the same time.  On top of that, in order for a reverse-engineered life to work, it would have to be put together by an architect who knows the future.

Does such a worldview exist?  Yes.  But not as a system.  It is a person: Jesus.  Jesus is himself God.  This means he is present in the past and the future.  This means also that he knows everything and is everywhere at the same time.  The only way to have a comprehensive worldview is not to find a workable religious system, but to instead have a relationship with Jesus Christ.  I’m not telling you that the answer is in Christianity.  It’s not in any system.  The only way to follow a comprehensive worldview is to follow a coherent, comprehensive leader.  That leader is Jesus.

One of the reasons I am not denominationally affiliated as a chaplain is because I want to emphasize in my ministry the centrality of Jesus.  Other chaplains are denominational, and that’s fine.  Many of them are Jesus followers within their denominations.  For me, though, as a chaplain I want to emphasize to you that Jesus is sufficient to handle all of life–marriage, parenting, war, PTSD, anger, worry, anxiety, distress, joy, happiness, excitement, hatred, democrats, republicans, infanticide, IED’s, sex, movies, music, deformities, jobs, lay-off’s, promotions, insurance, death…you name it.

To get a handle on all of life and to have the wisdom to lay out a reverse-engineered life, you will need to have a personal relationship with Jesus.  I don’t mean a cordial, informational understanding of the bible’s description and words of Jesus, but a true personal one-on-one relationship with him.  That sort of relationship provides for you a leader who is already in the future.  Jesus then becomes your guide in planning your life and working through your plan.  He’s there to show you where you got it wrong and where it needs to be adjusted.  He provides support and grace and strength during the tough parts.  He reassures you that everything really is under control when life seems to spiral out of control because of a diagnosis.  And in the end, regardless of how life went, he brings you home to heaven.  Guaranteed.

The perfect worldview is not a system, a philosophy, or an ideology.  It is Jesus.

Next in this series: Sin, Jesus, and the Perfect Plan.

The following is a case study of a software maintainability assessment method. The organization using this method, Footech, and the Foo software are  fictional. 

1.  Introduction

In August 2009, management of Footech Ltd decided to conduct a maintainability assessment of its Java-based legacy software, Foo. This report was written in response to the request from the CEO of Footech, Mr. Bob Brown, to analyze the findings of this assessment and investigate the effectiveness of the current maintainability assessment method.

The report firstly outlines the maintainability assessment method and includes a maintainability index (MI) for Foo. It then, based on the results of the MI, discusses the maintenance requirements for each deficient aspect of the system and introduces commonly used maintenance tools. Thirdly, the currently used maintainability assessment method is analyzed to determine limitations and identify improvements. Finally, a commonly used MI model, the Coleman-Oman regression model, is examined as a consideration for future MI developments. Conclusions are then drawn from these findings.

 

2.  Discussion

2.1  Maintainability assessment method 

The software maintainability assessment method currently used by Footech is based on a table of factors as shown below.

a.         Each factor is awarded a score between 0 and 10 by an engineer who knows the system, to indicate how maintainable the system is relative to that factor. For example, a relatively old system may be awarded a score of 8 out of 10 to indicate that due to its age the system will be relatively difficult to maintain.

b.         Each factor will have been assigned a weighting between 0 and 10 by a group of experienced software engineers to indicate its importance to the overall maintainability of the system – the higher the score the less maintainable the system.

c.         The scores for each of the factors assessed are then multiplied by the appropriate weighting and the resultant products are then summed to give an overall score which forms the maintainability measure (MM) of the system (the lower the score, the better the maintainability of the software system).

d.         If the overall score is more than 300, something needs to be done about the system.

2.2 Maintainability assessment index

The following table represents maintainability of the Foo software system according to the aforementioned maintainability assessment method.

2.3 Maintenance requirements

Footech’s maintenance assessment method calls for maintenance work to be carried out if the MM is over 300, so with ten factors examined, the most each factor should score is 30. Six out of the ten factors scored higher than 30 with the highest, application complexity, scoring more than double the acceptable level. These factors are individually examined below with a view to how the maintainability of each can be improved. Examples of tools that can assist maintainability are also given.

 2.3.1 Application complexity

An excessive level of application complexity indicates that the Foo software architecture may be inappropriate for intended changes, and to some extent, the system needs to be re-engineered. In order to reduce complexity of an application the software firstly needs to be understood. Without sufficient documentation, as in this case, reverse engineering is necessary to find higher level descriptions of the system for re-documentation.  Reverse engineering tools include call graphs, to assist understanding of software processes by mapping the relationships between system subroutines, and execution tracers, to track execution through the software. Profiling tools, such as JProfiler, are also useful to calculate and produce a visual indication of which part of the program needs to be optimized. 

Main screen of JProfiler

After sufficient reverse engineering, the system can be forward engineered to produce an improved, restructured version of the same program, with decoupled and cohesive modules. Complex modules are prone to error, require many tests and are harder to understand and to modify. Therefore, when forward engineering, application design should divide modules so that each module is of equal or near equal complexity, with no module being overly complex. To achieve this, a measure of complexity must be established and options should be evaluated against this measure. The option that results in near equal measures for each module can then be selected. To find a good threshold, a software metric developed by Thomas McCabe called Cyclomatic Complexity can be used to measure the number of linearly independent paths through the program’s source code. Enerjy, a free plug-in for Eclipse, measures complexity via the system’s cyclomatic complexity number.

Enerjy Memory Profiler used within the Eclipse IDE

There are some basic change processes that must be followed while forward engineering. These include configuration management, to ensure compatible software versions, and release planning, which prioritises changes to the system. Regression testing is a critically important process in software evolution to ensure previously implemented functionality still works after bug-fixes. 

2.3.2 Code annotation

To make programming tasks simpler, source code annotation provides a way adding of metadata to code that is available to programmers at runtime. In Java EE 5, it enables code reduction through injecting dependencies, resources, services, and life-cycle notifications into the application.

In addition, code annotation makes it possible for a Footech team member to view a complete history of current code lines in one view, with details including the developer who wrote the code, date and time, and a link to other files checked in at the same time. This makes it valuable for team development and fixing bugs in legacy code, such as Foo, as there is an easy means of collaborating with the writer of the code and a link to possibly related files. Eclipse has strong support for annotation, and an added benefit of using annotations in Eclipse is that the Eclipse Annotation Processing Tool can be used to generate files and compile new java classes based on annotations found in the source code.  

2.3.3 Change history documentation

Following Footech’s QA program, in order to produce high-quality software, programmers must follow a strict set of coding standards. One reason why maintaining change history documentation is important is to ensure that these quality assurance practices are followed properly. Therefore, Foo’s source code should be managed in a way that each modification performed is traceable.  Improved tracking of detailed history per module allows management to better identify risks, resolve issues, and improve planning of projects.

The Perforce Source Control Management System from ThoughtWorks provides access to versioned files by treating each change made to code as a submission, where a change-list card is filled out with a change description. Each item in a change-list is associated with a module of the project to allow traceability and enable monitoring of coding practices. Repository code is easily accessed via quick links from its associated “story”, or module, and all changes can be monitored from a dashboard. Additionally, changes can be visualized through dynamically generated, customizable reports. All this enforces accountability for Footech engineers, fostering quality development software procedures.

Perforce Source Control Management change submission

The choice between an efficient and inefficient algorithm can make the difference between a practical and impractical solution to a problem, so it is important that resources used during execution of the Foo program can be measured. Complexity theory provides a means for measuring resources needed for a computation to solve a given problem. According to this theory, the complexity of a data structure relates directly to how much time and space (computer memory) the algorithm uses, or how efficient it is. Time complexity is the number of steps involved in a solution to solve a problem and space complexity focuses on the number of elementary objects that a program needs to store during its execution. Big-theta notation is a common metric for calculating time and space complexity, where all constant factors are removed from a function so that the running time can be estimated in relation to N as N approaches infinity, allowing users to concentrate on growth rates of the algorithm. In algorithm analysis, it is common to classify algorithms according to shapes of their graphs, normally based on worst-case analysis. Using these graphs to analyze Foo’s data structures can assist with the software’s maintainability.

2.3.5 Architectural documentation

An architectural document lays out the general requirements that would motivate the existence of a routine. This would include Foo’s major software components and their interactions, a description of Foo’s hardware and software platforms, and a justification of how the architecture meets requirements. “A good architecture document is short on details but thick on explanation” (2009, Software documentation).

Common problems involved with creating good architecture documentation are fragmentation of documentation, non-standard modeling conventions, duplication, and inconsistent information. A pragmatic solution would be to use a wiki, such as Confluence, together with a UML tool, like that of Sparx Enterprise Architect, to facilitate knowledge management and documentation of the Foo software. Another benefit of using Enterprise Architect is that it also includes version control for change history documentation.

Enterprise Architect UML

2.3.6 Code complexity

Code complexity can be reduced by using object-oriented programming (OOP) techniques such as information hiding, data abstraction, encapsulation, modularity, polymorphism, and inheritance, which help build a flexible and scalable application. Footech programmers who are educated in the principles of OOP programming can identify code deficiencies and implement refactoring when necessary. Because refactoring does not change the behaviour of the system, to some, the process may be seen as a drain on resources, but it is in fact conducive to faster programming and essential for building a quality system. Ideally, refactoring should be included in Footech’s normal activities. Extreme programming fosters a refactoring culture and is designed to adapt to changes. Key practices include iterative development, self testing code, and pair programming (with one programmer being a class writer and the other a class user) to encourage evolutionary design.

2.4 Limitations of current assessment method
 
The current maintainability assessment method requires that a score is given to each factor by “an engineer who knows the system”. This doesn’t specify how the Footech engineer should gain knowledge about the system in order to rate it. Without this specification, the engineer might be tempted to base the score on personal experience with the system, introducing the risk of human error. Moreover, Footech engineers are given the difficult task of rating factors, relative to each other, based on their importance to the system’s maintainability. This method is overly subjective, relying solely on opinion. Cognitive factors can influence how people answer questions, such as latter answers being influenced by prior answers. Engineers may not make the required mental effort to recall all the relevant information, and worse still, attitudes given toward a factor may not even exist in a coherent form. Nevertheless, considering the scale of the factors involved, accurate estimation of Foo’s system maintainability is beyond the ability of even experienced engineers.
 
To reduce this uncertainty, a more objective approach would be to analyze Foo software’s source code and system metrics to better facilitate understanding of the underlying software. Metrics are useful to estimate effort, both already done and expected in the future, and almost every metric is more useful than none at all. Using design metrics to investigate software trends in the system provides a better indication of software quality, and the discovery of trend correlations lends to fact-based, informed decisions for preventative maintenance. Conveniently for programmers using a metric-based MI, tools exist to automatically calculate the maintainability score, whenever code changes are made.
 
A repository to store Foo’s software history should be kept, which can be accessed by a software trend analyzing tool, such as Solid Trend Analyzer from Solid Source. This provides graphs and diagrams based on metric data, such the rate of edit file addition, system proportion of complex files, and the size of frequently changed files. Such information is invaluable to allow cost reduction, quality improvement, and decision making support.

Addition rate of edit files

Another useful indicator of maintainability for the Foo application is the Object-oriented Metrics Suite, originally put forward by Chidamber & Kemerer, which consists of six metrics for each class in an application. It utilizes measurement theory to improve object-oriented design and development processes, and provides structural measures as indicators of maintainability. For example, the Coupling Between Objects (CBO) measure is the count of classes to which a class is coupled, with a higher CBO indicating more difficult testing, maintenance, and reuse.

Although the aforementioned methods have been proven to improve maintainability of a system, and the current maintainability assessment method would benefit with some level of incorporation, there are still some unresolved issues with software maintainability, especially with those that arise when software components are built with different programming languages and technologies. The current assessment method doesn’t consider the variability of languages and technologies, and could be improved if these are taken into account. Other considerations for maintainability include the time taken to fix a defect (time to mean change), the backlog of user requests, and the ratio between initial development and defect fixing costs.

2.5 Maintainability Index structure

In order to improve Footech’s current maintainability assessment method, it is important to examine ways that a maintainability index can be structured. The most commonly used model for determining the maintainability index of a software system is the Coleman-Oman regression model, which was developed in the 1990’s by the University of Idaho, as shown in the polynomial expression below.

where:

• aveV is the average Halstead Volume per module.
• aveV(g’) is the average extended cyclomatic complexity per module.
• aveLOC is the average lines of code per module.
• perCM is the average percent of lines of comment per module.

Source: Liso, A. (August, 2001)

It was subsequently determined that this method was not satisfactory because comment blocks, which typically do not influence the maintainability of an application, were being included as lines of code. A second model was developed that is derived from the first model, but removes code comments from equation, as below.

This maintainability index is based on Halstead’s effort metrics, cyclomatic complexity (as described earlier), and lines of code. It attempts to “objectively determine the maintainability of software systems based upon the status of the source code” (Oman et. al) and can be calculated at method, class, package, and system level. Hewlet-Packard validated the index in the field and determined that, on scale from 1 to 100, modules scoring more than 65 are considered difficult to maintain. The index has been successfully tested on large-scale military and industrial systems. It is interesting to note that there is a high correlation between modern-day system metric tools, as examined earlier, and the principles used in the Coleman-Oman regression model.

The first component of the model, Halstead metrics, is primarily based on the number of operators and operands in a system, indicating how complex the application’s statements are. Measurements include Halstead Length, Vocabulary, Volume, Difficulty, Effort, and Bugs. These measurements provide valuable insight into which areas of the application need to be modified, such as Halstead Vocabulary, which counts the number of different variables, or Halstead Difficulty, which counts unique operators and operands. The measurements can also be used together in calculations to determine various aspects of an application’s complexity. For example, a small Halstead Length, or number of statements, with a high Halstead Volume suggests that individual statements are overly complex.

Metric measurements become more difficult to calculate where the data is more semantic in nature, such as determining the appropriateness of data structures and meaningful documentation. Therefore, as with Halstead Effort and Bugs which can not be inherently analyzed through code analysis, a certain amount of estimation is required. Pizka et al. propose one possible solution to this may be to use a broader “quality model” tree instead of a maintainability index. This would include a technical dimension of “maintainability” as a top-level quality attribute of a system, with more concrete attributes like “analyzability” on lower levels. The values determined by the metrics are then aggregated towards the root of the tree to obtain values for a higher level.

3.  Conclusions

1.      According to Footech’s maintainability index there are six aspects of the Foo software system that require maintenance. These are: application complexity, code annotation, change history documentation, data structures complexity, architectural documentation, and code complexity. Maintaining each of these factors involves specialized requirements and tools.

2.      Footech’s maintainability assessment method is overly subjective.

3.      The maintainability assessment could be improved by using design metrics to judge the quality of the system design and identify candidates for preventative maintenance.

4.      The Coleman-Oman regression model is a well-tested, commonly used method for determining the maintainability index of a system. It uses Halstead metrics and McCabe’s cyclomatic complexity, along with other factors, to determine an indicator of a systems overall maintainability.

5.      Functionality of many modern-day system metrics analysis tools is based on techniques used in the Coleman-Oman regression model for developing a maintainability index.

TurboDiff is a new IDA Pro plugin for binary patch diffing by Nicolás Economou. Binary diffing in this context means the analysis of a vendor-supplied patch (such as Microsoft Tuesday patches, for example) to find out exactly how the vulnerability it’s fixing works. This is essential in both developing an effective IDS signature (from a defensive standpoint) and a working exploit for it (from the attacker’s point of view).

As you can surely guess, doing a naive byte per byte comparison of the files before and after applying a patch simply doesn’t work. Any modern compiler performs a number of optimizations and small changes that vary from one compilation to the next – not to mention the changes introduced by changing to a new compiler version altogether. What binary diffing tools do to cope with this is analyze the semantics of the code by breaking it up into basic blocks (like IDA does to disassemble from version 5.0 and above) and matching them using one or more graph comparison algorithms. First each function needs to be identified and matched in each binary, despite of the reordering of code blocks made by the compiler. Then, each function’s basic block graph from each binary must be compared to look for differences.

This technology is not really new – there are other tools (Zynamic’s BinDiff, eEye’s DarunGrim, Tenable’s PatchDiff) and several papers published on the topic. I very much recommend to read Tyler Durden’s article on the Phrack Magazine, Julien Vanegue’s Ekoparty presentation, and the CanSecWest 2009 talk from Thomas Dullien and Sebastian Porst. There’s also a very interesting presentation at BlackHat USA 2009 by Jeongwook Oh on anti-binary diffing techniques, to thwart reverse engineers efforts to analyze patches. I’m probably forgetting something else, but Google is your friend.

TurboDiff, however, takes on a much more simple approach to binary diffing. While other tools are using intermediate language decompilers and very complex general purpose graph algorithms, which take a long time to run, TurboDiff applies a series of optimized heuristics tried and tested on real life examples, and custom made graph algorithms specific to the kind of output a compiler may generate. The result of this is an incredibly fast binary diffing tool: it spits out the diff in only a few seconds for a patch that other tools may take literally days to chew on! If anythink, this alone justifies it’s use: there’s so little effort involved in trying this out, you might as well look at it’s results while your other diffing tool is still working in the background…

But there’s another benefit – many times I’ve seen it point out changes in a patch that some of the other differs could not find. Here’s a real life example from the Microsoft Tuesday patch for MS09-023:

Unpatched

Patched

Those are the pros, but naturally there are also cons. This tool is still on it’s first released version, so many bugfixes and improvements are to be expected in the near future. The user interface is still a bit sketchy, but nothing one can’t get quickly used to. Also, it’s mostly focused on reversing patches, while other tools may be more flexible due to the nature of the algorithms they use – most notably, BinDiff is also used for symbol porting as explained by Halvar Flake in his blog.

So, enough reading! It’s time to start reversing some patches to see and judge for yourself!

Download

IDA plugin with sources:

turbodiff_v1.0.1.zip

Det fremføres ofte i debatten, at biometri er offentlig tilgængelig information. Vi aflægger vore fingeraftryk alle vegne (på ølglas, dørhåndtag osv.) og vore ansigter afbildes på fotos, der lægges på internettet endda uden at vi selv ved af det.

Men denne uafvendelige kendsgerning udelukker ikke, at biometriske kendetegn er og bliver unikke. De er bare ikke hemmelige. Udfordringen for leverandørernes forskning- og udviklingsafdelinger består i, at gøre dem hemmelige. Og hvorfor det ? Fordi en kompromitteret biometri ikke kan erstattes. Du kan ganske vist designe et biometrisk system med substituering af op til ni fingre og en iris (alle dine fingeraftryk er forskellige og selv din venstre iris er forskellig fra din højre). Men en forfalsket biometri er tabt for altid.

Det er også en kendt sag, at især fingeraftryksbiometri kan hackes eller spoofes. Hvorledes dette kan lade sig gøre har den tyske Chaos Computer Club bl.a. givet tips om i en videosekvens. For fuldstændighedens skyld skal det imidlertid anføres, at disse angreb ofte gennemføres i laboratorier, på baggrund af en forud indhøstet indgående viden om det biometriske system og hvor positive tests ofte først lykkes efter mange forsøg. Men selv om det i den virkelige verden vil være endog meget svært at gennemføre en hacking, så udelukker det dog ikke, at det principielt er muligt.

Derfor tages disse eksempler alvorligt og er faktisk med til løbende at forbedre teknologien. Hidtil er dette sket ved at raffinere sensorerne (f.eks. med anvendelse af multispektral billedanalyse), at fusionere flere forskellige biometriske modaliteter (f.eks. fingeraftryk og iris), at supplere med PIN-koder mm.

Når det er sagt, så hersker der heller ikke nogen tvivl om, at passwords (eller noget du ved) og smartcards alene eller i kombination heller ikke giver sikker autentificering, eftersom de enten kan glemmes eller tabes og ydermere ikke effektivt kan bindes til en person, hvorved systemet ikke kan differentiere mellem en legitim bruger og angriber.

Når nu biometri ikke er hemmelig,hvorfor så ikke dels kryptere disse data og derudover benytte biometri som en krypteringsnøgle ? At kryptere den biometriske template i en database kan lade sig gøre på sædvanlig vis og vil forbedre systemets security, men spørgsmålet om privacy er uløst, i de tilfælde hvor kontrollen med krypteringsnøglerne og dermed af de biometriske data er hos ejeren af en centraldatabase (i modsætning til en lokaldatabase). Det andet spørgsmål kan imidlertid ikke umiddelbart lade sig gøre, fordi de biometriske data (templates) er forskellige af natur. Hvert nyt realtime fingeraftryk er forskelligt og konventionel kryptering tolererer ikke en eneste bitfejl. Derfor koncentrerer nyere forskning sig i stedet for at udvikle metoder til at binde en krypteringsnøgle til de biometriske data, således at nøglen hele tiden kan regenereres.

Forskningen kaldes for biometrisk kryptering og defineres som en proces, der på en sikker måde binder (ikke indlejrer) en PIN eller en krypteringsnøgle til biometrisk data, så hverken nøglen eller de biometriske data kan udledes fra den gemte template. Nøglen kan kun dekrypteres med den registrerede persons realtime biometriske data, f.eks. et fingeraftryk. Hermed kan man dekryptere en PIN, et password eller en alfanumerisk streng for adskillige applikationer.

Det vil føre for vidt at komme nærmere ind på de forskellige modeller for biometrisk kryptering i denne omgang, men temaet vil blive taget op ved en senere lejlighed. Nogle hovedprincipper kan dog anføres:

• brug af biometriske eksemplarer (f.eks. friske fingeraftryk) og biometriske templates anvendes kun for at danne samt verificere bestemte pseudo-identiteter (som ikke må indeholde biometriske data) og det biometriske eksemplar så vel som den biometriske template må ikke gemmes overhovedet.
• undgå at biometriske data eller andre data kan benyttes til at udlede en bestemt persons identitet
• undgå at biometriske data eller andre data kan bruges til at linke personer (data-subjekter) på tværs af databaser (function creep)
• begrænse processen af persondata til et absolut minimum
• slette det biometriske eksemplar og den biometriske template (rodidentitet) så hurtigt som muligt efter processen, såfremt disse ikke er nødvendige til brug for processens formål
• udelukke rekonstruktion af det biometriske eksemplar fra den biometriske template (uden reverse engineering)
• gøre brug af lokal database samt verifikationsfunktion og gemme persondata på en device under kontrol af data-subjektet (match-on-card eller system-on-card)
• undgå at nogen yderligere persondata er direkte linket til de biometriske data (til brug for den midlertidige proces), såfremt dette ikke er nødvendigt for processens formål
• informere brugeren (datasubjektet) om systemets formål, funktion og proces
• såfremt det kræves, at enhver bestemt pseudoidentitet genereres fra et nyt (frisk) biometrisk eksemplar med henblik på at øge gennemsigtighed
• generering af forskellige pseudoidentiteter, som til enhver tid kan tilbagekaldes af datasubjektet, til forskellige applikationer

Lad os forestille os et scenarie med brug af en biometrisk krypteringsløsning i forbindelse med eksempelvis receptudskrivning.

1. Patienten (datasubjektet) besøger sin læge, der skriver en recept. Recepten sendes til patientens indbakke på den landsdækkende receptserver.
2. Derhjemme, bruger patienten sin personlige computer til at få adgang til receptserveren. Via en sikker forbindelse, autentificerer receptserveren sig overfor patientens smartcard, og som ved denne autentificering ved, hvilken indbakke, der skal åbnes. I indbakken er gemt de yderligere data, der kræves for at udføre hybridverifikationen. Patientens realtime biometriske data bruges sammen med de supplerende oplysninger til at oprette en midlertidig pseudo-identitet (PI1*). Denne bliver herefter sendt til den centrale applikation og sammenlignes med en tidligere (ved registreringen) gemt pseudo-identitet (PI1). Eftersom der er en match får patienten adgang.
3. Herefter finder patienten den pågældende recept i indbakken og tildeler apoteket adgang til den. Dette sker ved at etablere et link mellem recepten og den pseudo-identitet, som patienten gør brug af på apoteket.
4. På apoteket bruger patienten sit personlige smart card i forbindelse med apotekets terminal ( indstiks- eller berøringsfri læser). Terminalen autentificerer sig selv og får adgang til sin indbakke på patientens smartcard, hvor yderligere data til brug for verifikationsprocessen er gemt. Ved at bruge patientens realtime biometriske data (via en scanner på f.eks. selve patientens smartcard) sammen med de supplerende oplysninger, kreeres en midlertidig pseudo-identitet (PI2*), der sammenlignes med den oprindelige (PI2), der er gemt på patientens smartcard ved registreringen. Apoteket’s system sammenligner de to pseudo-identiteter, og eftersom der er et match, kan systemet nu bruge pseudo-identiteten til at søge efter linkede recepter.
5. Den recept, der er linket til patientens ”apotek-pseudo-identitet” bliver fundet og patienten kan få sin medicin. Apoteket opdaterer recepten med bemærkning om hvilken medicin der er blevet udleveret.

Biometrisk kryptering kan således både sikre security og privacy. Sådan som de biometriske data indgår i processen ved kun at blive anvendt ved registreringen af en person, hvorefter de transformeres til pseudoidentiteter, kan man faktisk ikke mere definere biometri som “noget du er”, men mere som “noget du har”, nemlig unikke pseudoidentiteter.

Det komplette koncept kan i øvrigt også indeholde “noget du ved” (hybridverifikation), hvorefter der sker en effektiv integration af alle hidtil kendte autentifiseringsmetoder. Man kan med rette tale om den højeste grad af en privacy enhancing technology-løsning.

Biometrisk kryptering bør være en obligatorisk feature for et fremtidigt dansk borgerservicekort.

På Danish Biometrics blog i undermenuen biometrisk kryptering kan man finde yderligere information om biometrisk kryptering.

Det fremføres ofte i debatten, at biometri er offentlig tilgængelig information. Vi aflægger vore fingeraftryk alle vegne (på ølglas, dørhåndtag osv.) og vore ansigter afbildes på fotos, der lægges på internettet endda uden at vi selv ved af det.

Men denne uafvendelige kendsgerning udelukker ikke, at biometriske kendetegn er og bliver unikke. De er bare ikke hemmelige. Udfordringen for leverandørernes forskning- og udviklingsafdelinger består i, at gøre dem hemmelige. Og hvorfor det ? Fordi en kompromitteret biometri ikke kan erstattes. Du kan ganske vist designe et biometrisk system med substituering af op til ni fingre og en iris (alle dine fingeraftryk er forskellige og selv din venstre iris er forskellig fra din højre). Men en forfalsket biometri er tabt for altid.   

Det er også en kendt sag, at især fingeraftryksbiometri kan hackes eller spoofes. Hvorledes dette kan lade sig gøre har den tyske Chaos Computer Club bl.a. givet tips om  i en videosekvens. For fuldstændighedens skyld skal det imidlertid anføres, at disse angreb ofte gennemføres i laboratorier, på baggrund af en forud indhøstet indgående viden om det biometriske system og hvor positive tests ofte først lykkes efter mange forsøg. Men selv om det i den virkelige verden vil være endog meget svært at gennemføre en hacking, så udelukker det dog ikke, at det principielt er muligt.   

Derfor tages disse eksempler alvorligt og er faktisk med til løbende at forbedre teknologien. Hidtil er dette sket ved at raffinere sensorerne (f.eks. med anvendelse af multispektral billedanalyse), at fusionere flere forskellige biometriske modaliteter (f.eks. fingeraftryk og iris), at supplere med PIN-koder mm.  

Når det er sagt, så hersker der heller ikke nogen tvivl om, at passwords (eller noget du ved) og smartcards alene eller i kombination heller ikke giver sikker autentificering, eftersom de enten kan glemmes eller tabes og ydermere ikke effektivt kan bindes til en person, hvorved systemet ikke kan differentiere mellem en legitim bruger og angriber.  

Når nu biometri ikke er hemmelig,hvorfor så ikke dels kryptere disse data og derudover benytte biometri som en krypteringsnøgle  ?  At kryptere den biometriske template i en database kan lade sig gøre på sædvanlig vis og vil forbedre systemets security, men spørgsmålet om privacy er uløst, i de tilfælde hvor kontrollen med krypteringsnøglerne og dermed af de biometriske data er hos ejeren af en centraldatabase (i modsætning til en lokaldatabase). Det andet spørgsmål kan imidlertid ikke umiddelbart lade sig gøre, fordi de biometriske data (templates) er forskellige af natur. Hvert nyt realtime fingeraftryk er forskelligt og konventionel kryptering tolererer ikke en eneste bitfejl.  Derfor koncentrerer nyere forskning sig i stedet for at udvikle metoder til at binde en krypteringsnøgle til de biometriske data, således at nøglen hele tiden kan regenereres. Forskningen kaldes for biometrisk kryptering og defineres som en proces, der på en sikker måde binder (ikke indlejrer) en PIN eller en krypteringsnøgle til biometrisk data, så hverken nøglen eller de biometriske data kan udledes fra den gemte template. Nøglen kan kun dekrypteres med den registrerede persons realtime biometriske data, f.eks. et fingeraftryk. Hermed kan man dekryptere en PIN, et password eller en alfanumerisk streng for adskillige applikationer.

Det vil føre for vidt at komme nærmere ind på de forskellige modeller for biometrisk kryptering i denne omgang, men temaet vil blive taget op ved en senere lejlighed. Nogle hovedprincipper kan dog anføres:

 •  brug af biometriske eksemplarer (f.eks. friske fingeraftryk) og biometriske templates anvendes kun for at danne samt verificere bestemte pseudo-identiteter (som ikke må indeholde biometriske data) og det biometriske eksemplar så vel som den biometriske template må ikke gemmes overhovedet.
• undgå at biometriske data eller andre data kan benyttes til at udlede en bestemt persons identitet 
• undgå at biometriske data eller andre data kan bruges til at linke personer (datasubjekter) på tværs af databaser (function creep)
 • begrænse processen af persondata til et absolut minimum
• slette det biometriske eksemplar og den biometriske template (rodidentitet) så hurtigt som muligt efter processen, såfremt disse ikke er nødvendige til brug for processens formål
• udelukke rekonstruktion af det biometriske eksemplar fra den biometriske template (uden reverse engineering)
• gøre brug af lokal database samt verifikationsfunktion og gemme persondata på en device under kontrol af datasubjektet (match-on-card eller system-on-card)
• undgå at nogen yderligere persondata er direkte linket til de biometriske data (til brug for den midlertidige proces), såfremt dette ikke er nødvendigt for processens formål
• informere brugeren (datasubjektet) om systemets formål, funktion og proces 
• såfremt det kræves, at enhver bestemt pseudoidentitet genereres fra et nyt (frisk) biometrisk eksemplar med henblik på at øge gennemsigtighed
• generering af forskellige pseudoidentiteter, som til enhver tid kan tilbagekaldes af datasubjektet, til forskellige applikationer

Lad os forestille os et scenarie med brug af en biometrisk krypteringsløsning i forbindelse med eksempelvis receptudskrivning.

1. Patienten (datasubjektet) besøger sin læge, der skriver en recept. Recepten sendes til patientens indbakke på den landsdækkende receptserver.
2. Derhjemme, bruger patienten sin personlige computer til at få adgang til receptserveren. Via en sikker forbindelse, autentificerer receptserveren sig overfor patientens smartcard, og som ved denne autentificering ved, hvilken indbakke, der skal åbnes. I indbakken er gemt de yderligere data, der kræves for at udføre hybridverifikationen. Patientens realtime biometriske data bruges sammen med de supplerende oplysninger til at oprette en midlertidig pseudo-identitet (PI1*). Denne bliver herefter sendt til den centrale applikation og sammenlignes med en tidligere (ved registreringen) gemt pseudo-identitet (PI1). Eftersom der er en match får patienten adgang.
3. Herefter finder patienten den pågældende recept i indbakken og tildeler apoteket adgang til den. Dette sker ved at etablere et link mellem recepten og den pseudo-identitet, som patienten gør brug af på apoteket.
4. På apoteket bruger patienten sit  personlige smart card i forbindelse med apotekets terminal ( indstiks- eller berøringsfri læser). Terminalen autentificerer sig selv og får adgang til sin indbakke på patientens smartcard, hvor yderligere data til brug for verifikationsprocessen er gemt. Ved at bruge patientens realtime biometriske data (via en scanner på f.eks. selve patientens smartcard) sammen med de supplerende oplysninger, kreeres en  midlertidig pseudo-identitet (PI2*), der sammenlignes med den oprindelige (PI2), der er gemt på patientens smartcard ved registreringen. Apoteket’s system sammenligner de to pseudo-identiteter, og eftersom der er et match, kan systemet nu bruge pseudo-identiteten til at søge efter linkede recepter.
5. Den recept, der er linket til patientens ”apotek-pseudo-identitet” bliver fundet og patienten kan få sin medicin. Apoteket opdaterer recepten med bemærkning om hvilken medicin der er blevet udleveret.

Biometrisk kryptering kan således både sikre security og privacy. Sådan som de biometriske data indgår i processen ved kun at blive anvendt ved registreringen af en person, hvorefter de transformeres til pseudoidentiteter, kan man faktisk ikke mere definere biometri som “noget du er”, men mere som “noget du har”, nemlig unikke pseudoidentiteter. Det komplette koncept kan i øvrigt også indeholde “noget du ved” (hybridverifikation), hvorefter der sker en effektiv integration af alle hidtil kendte autentifiseringsmetoder. Man kan med rette tale om den højeste grad af en  privacy enhancing technology-løsning. 

Biometrisk kryptering bør være en obligatorisk feature for et fremtidigt dansk borgerservicekort.

I undermenuen biometrisk kryptering kan man finde yderligere information om biometrisk kryptering.

Next week, the 16th Working Conference on Reverse Engineering (WCRE) will be held in Lille, France. I will be there presenting NTrace: Function Boundary Tracing for Windows on IA-32.

NTrace is a dynamic function boundary tracing toolkit for IA-32/x86 that can be used to trace both kernel and user mode Windows components — examples for components that can be traced include the kernel itself (ntoskrnl), drivers like NTFS as well as user mode components such as kernel32, shell32 or even explorer.exe.

NTrace implements a novel approach to instrumenting IA-32 machine code and integrating with the Structured Exception Handling facility of Windows. Using this approach, NTrace is not only capable of tracing nearly the entire Windows kernel and system libraries, it is also faster than Solaris DTrace FBT on IA-32!

Details on how exactly NTrace works will be publiched in the paper, which will be made available soon. I will also publish more details on NTrace both here and on a dedicated NTrace website.

The work, by the way, is basically the result of my Master’s thesis I wrote back in 2008.

Po patchu obchodzącym problem ograniczonej ilości rozdzielczości raportowanych przez NFS: PU na kartach zgłaszających ich dużą liczbę (rozwiązanie opisane jest w readme patcha, sposobu dojścia do niego nie będę opisywał, bo jest długi i ze względu na moje marne umiejętności z zakresu reverse engineeringu nudny – w skrócie użycie IDA Pro i  Hex-Rays Decompiler i żmudne rozszyfrowywanie kolejnych procedur), przyszedł czas na rozwiązanie problemu błędnego ustalania LOD (Level of Detail) dla tekstur na szybkich komputerach. Empirycznie stwierdzone zostało, że powyżej 2 GHz wszystkie tekstury używane są w najmniejsze wersji, co fatalnie wpływa na jakość grafiki.

Trzeba było tylko odszukać winny temu kawałek kodu. Poszukiwania zacząłem od sprawdzanie jak można sprawdzić szybkość procesora. Na x86 można tego dokonać z użyciem instrukcji Read Time-Stamp Counter (RDTSC). Poszukiwania w OllyDbg pokazały 10 miejsc w porsche.exe, gdzie można ją znaleźć. Postawiłem więc break-pointy zliczające wywołania procedur, w których RDTSC było wykonywane. W ten sposób udało się namierzyć procedurę wykonywaną przy uruchomieniu oraz na początku każdego wyścigu. Poprawka sprowadziła się do zmiany wartości zwracanej w procedurze:

0055609D  |. 75 08          JNZ     SHORT Porsche_.005560A7
0055609F  |. 8B4D F8        MOV     ECX, [LOCAL.2]
005560A2  |. 894D FC        MOV     [LOCAL.1], ECX
005560A5  |. 8BC1           MOV     EAX, ECX
005560A7  |> 8D0480         LEA     EAX, DWORD PTR DS:[EAX+EAX*4]
005560AA  |. 8BE5           MOV     ESP, EBP
005560AC  |. 5D             POP     EBP
005560AD  \. C3             RETN

na:

0055609D  |. 75 06          JNZ     SHORT Porsche.005560A5
0055609F  |. 8B4D F8        MOV     ECX, [LOCAL.2]
005560A2  |. 894D FC        MOV     [LOCAL.1], ECX
005560A5  |> B8 0000007F    MOV     EAX, 7F000000
005560AA  |. 8BE5           MOV     ESP, EBP
005560AC  |. 5D             POP     EBP
005560AD  \. C3             RETN

Wartość była zwracana w EAX, więc sprowadziło się to do wstawiania tam stałej 0x7F000000. Dodatkowo trzeba było zmienić skok @0055609D, bo wskazywał w powietrze. Parę osób, które przetestowało patch potwierdziło jego działanie.

Redirection:

http://evilcodecave.blogspot.com/2009/10/swimming-into-trojan-and-rootkit.html

Regards,

Giuseppe ‘Evilcry’ Bonfa’