Over the past month, while staying the fuck at home, I’ve been steadily chipping away at improving my tooling. These are below, for reference (and partly self-motivation).
First conceived years ago when I wanted to cheat in Underrail, this DLL injection tool injects a lua interpreter (accessible over IPC) and a stack of helper functions into a target process:
This toolset has been updated to work with a modern Win10 SDK, and has additional options for loading, such as create-suspended-and-overwrite-code and injection into .NET processes (you can’t really interact with the CLR, but you can execute as the target).
A number of quality-of-life fixes have also been implemented, including JIT function calls to native functions (stdcall 32-bit only, 64-bit WIP), QoL fixes to db/dw/dd(), and input via command files.
Interestingly, if you disassemble a .NET executable as a PE file, you’ll note a direct call to _CorExeMain (or _CorDllMain). Using the jmp $-2 trick and repatching the entrypoint doesn’t seem to work, you’ll need to insert a loader stub to manually call _CorExeMain (I’m not too sure why, please do comment if you know). Some interesting, related reading material is here.
Work is ongoing on the ability to “self-sustain” reflective DLL loading (preferrably without lugging around an image of doxastica into memory). Unfortunately, this doesn’t seem too easy with the MSVC Runtime’s initialization procedures – if you take a DLL from an “infected” process and try to copy it to another, you can manually sort out section addresses and relocs, but the MVSCRT strucutres are already done. It may be possible to copy an uninitialized copy of MSVCRT’s .data section over (but extremely brittle – but I think there are no “winner” approaches here). For what it’s worth, the code is available here.
I was hoping to take a group of people (some colleagues, some ex) through Pwn Adventure 3, but this has stalled – understandably, as the barrier of entry and time commitment requirement are both significantly higher than say, web security.
Following the example of ChipWhisperer and it’s spawned community projects, I’ve combined my previous attempts at SCA and FI into a single project, built off the ChipWhisperer, ChipSHOUTER and a custom FPGA back-end (implemented on an Arty A7 35-T board) and some scrap protoboard glitch inserters.
The primary change is a change from paragraph-long command lines, to a console interface like this (with input-from-file support):
The new “capturebuddy” interface no longer requires significant rework every time I want to use a different oscilloscope or driver interface: I simply set up a “driver” (which controls target logic) and a “frontend” (representing capture hardware), and capturebuddy takes care of the rest.
A standalone “triggerbuddy” utility is also provided – this can be imported to control the FPGA trigger interface from a console, or imported as a library to automate the same. The trigger mechanism is extraordinarily simple, but imo adaptable to most protocols. You set four configuration parameters (io, clk, ns and pulse width), the FPGA waits for io_count rising edges on the io line, then clk_count edges on the clock line, then ns_edges *rising* edges on an internal 400Mhz clock, and generates a pulse of 0.5ns*pulsewidth out. No consideration is given to synchronous measurement (later project), but given the structure of the verilog, you can just extend the “master” ns_clock to implement this: CW1200 SAD-match functionality here we come!
I also did some further investigation into why my previous smartcard triggering introduced such extreme jitter – I’m confident enough in my Verilog now that I believe this is due to the 1.8V smartcard transmission not being detected by the 3.3v I/O ports on the FPGA board. It would detect in say, 99% of cases but fail occasionally (and this effect would horribly cascade over thousands of edges).
My initial attempt at resolution was to use two 2N3904’s to level shift up to 3.3v, but this creates “lag artifacts” during the level shift process and completely obliterates the clock line (input resistance slowing the changes?):
(Image from https://electronics.stackexchange.com/questions/333229/1-8v-uart-with-3-3v-uart, replace UART with IO and CLK).
Based on overall project status, I felt that I would be better off writing my own smartcard reader/writer:
The code for the improved sparkgap framework are here, and will include the smartcard reader/writer once it’s somewhat stable.
I’m once again lecturing at UNSW, though this time remotely. I’ll be teaching the COMP6443/6483 Web Application Security and Extended Web Application Security courses. This is an excellent opportunity to revamp the entirety of the course, now with an expanded support team – to clean up old content, integrate new tooling and techniques and reinvigorate the course.
As I’m doing this, I can’t help but draw parallels to this video:
While there have been new innovations in web security (mostly dealing with scale, not the “innovations” of crawling the darkweb with blockchain regex machine learning cyber cloud), we’re still teaching students about how to exploit SQL injection as a “core building block”.
It’s my hope that instead of continuing in this path, the 2020 revamped web security courses will focus more on underlying concepts of code injection (the mixing of code and data, instead of SQLi) and that students can more intuitively grasp SQLi – and moving forward, we can eventually drop traditional SQLi and XSS as topics (again, focussing on underlying concepts so students can intuitively derive these attacks, no matter the defenses in play). From the students perspective, they’re paying good money to learn, we should provide something of value, not hand them a stack of pre-made attacks they can stack together like lego.
My thanks to everyone who has contributed to this course so far, and to everyone who is working on the course this year.
: This is an interesting talk around the “Security Products we Deserve”, and is well worth watching for some insight into this problem.