Quick Notes on the PSoC

Today, I spent some time tinkering with the PSoC 5 LP prototyping kit. This prototyping kit is physically very portable, and contains some very surprising features for it’s price point (~$10-20, depending on supplier). Unfortunately, I had horrendous trouble navigating the documentation, so I write this blog post both as a note to myself, and hopefully to assist anyone else trying to work out how to use PSoC Creator.

The uniqueness of PSoC comes from a number of analog components which are directly accessible from the MCU itself, and the flexbility of the microcontroller pins. Think of it as a microcontroller on top of an FPGA on top of a stack of analog components (for the princely sum of $16) and you’re there. I think this is extremely cool, and hope you do to.

To start, let’s try driving a status LED from the firmware. After creating a new project and selecting the correct development kit, we are presented with a blank schematic. We begin by using the Component Catalog tab on the right to add a Digital Output Pin (under Ports and Pins). We drag this to our schematic:

Think of this pin as an arbitrary “slot” – this isn’t connected to anything yet. We double click the pin on the schematic, and untick “HW Connection”. Leave the rest as-is (strong drive, we’re driving a LED).

Our next step is to map this to a physical pin. Click the components tab on the left hand side, to bring up a tab which looks like a square microcontroller:

On the right, you’ll have a window which allows you to assign Pin_1 to a port. The “port” corresponds to the port numbers printed on the prototyping kit’s silk screen. For this example, we inspect the physical LED element, and we note it says “2.1” underneath the LED. We select “P2[1]” for the “Port”, and leave the rest as-is. The middle picture should change, with P2[1] becoming blue to denote the change:

This is enough to begin programming on the microcontroller. Click the “Sources” tab on the left, and open “main.c”.

The code generation is unfortunately a bit strange. You’ll need to use a few Cypress functions to do things. A LED blink looks like this:

#include "project.h"

int main(void)
 CyGlobalIntEnable; /* Enable global interrupts. */

/* Place your initialization/startup code here (e.g. MyInst_Start()) */


Now, save your work, compile your project then program this to your dev kit (the board comes with a KitProg programmer built in, similar to the STMicroelectronics boards), you should get a blinking LED.

Note that I had problems getting the PSoC4 equivalent (CY8CKIT-049) working, and I ended up resorting to an external MiniProg programmer to make this work. YMMV, this may just be hardware damage on my end.

Now, let’s replicate the functionality in programmable logic and reroute the output. Firstly, go to the Components tab on the left, and right click the “Project ‘Design01′” row (or whatever you named it), and click “Add Component Item”. Do not use this while TopDesign is selected, or you can unfuck your project later.

Now, use the Symbol Wizard to define a clock input and a simple digital output:

You should be presented with another schematic-looking thingy. Right click the blank space, and select “Generate Verilog”. Now, use the following code to create a blinker:

reg [32:0] ctr;
reg led_out_r;
assign led_out = ctr[27];

ctr <= 0;

always @(posedge clk_in)
 ctr <= ctr + 1;

Note that this is a bit stricter than Xilinx’s Vivado: we need an explicit initial block instead of just assigning variables at the start. Enter this in the body section of your Verilog, and save your work.

Our next step is to add a clock input, and connect it to our LED. Select the “TopDesign.cysch” tab up the top, and modify our pin to enable “HW Connection”. Now, use the Component Catalog’s “Default” tab on the right to add one instance of our new component:

Now, connect the two components, using this tool to the left of your schematic:

Note that this tool is a “clicking only” tool, and does wierd things if you attempt to drag like a normal person. Instead, click once and only once on the starting component’s “connector box”, and click once and only once on the end component’s connector box. A successful connection looks like the above.

Now, use the Component Catalog on the left to add a Clock (under the “Cypress” tab, in “System”). Leave this at whatever the frequency is, and wire it up:

Now, go to main.c, and delete the code we added (so leave it as an empty main function). Build your project, and program it, for a very slowly blinking LED.

You can easily redirect ythe output to another pin – simply open Design01.cydwr (the MCU square thing), and select a new port (P2.0 is an excellent choice for testing – it’s right in the corner), rebuild and reflash your project.

I look forward to working more with this interesting hardware.

Posted in Bards, Computers, Jesting | Leave a comment

Writeup – El33t Articles Hub (Pragyan CTF)

This weekend, I participated in Pragyan CTF. In the time allocated, I solved a few challenges – unfortunately, most of them are not worth writing about, in that they are very similar to previous writeups.

I will present a writeup for one of the web challenges below.

El33t Articles Hub

This was a web challenge, with the challenge text as follows:

On visiting the website, we are taken to the following web page:

Viewing the source code gives us an interesting clue: that a dynamic favico is being generated:

A bit of guesswork reveals that this is vulnerable to a path traversal bug, and a little bit of exploration later reveals the source code for index.php, and more importantly, helpers.php:

Some fiddling with the path on the webserver later, gives us the flag:

Thanks to the Pragyan organisers for putting together this event – unfortunately, it quickly became apparent that this event was not ready for deployment, and some of the challenges had undergone insufficient playtesting. Also, the entire “Misc” category disappearing while the CTF was on is pretty much never a good sign.

Interestingly, someone in my university class asked last week, “is every website this vulnerable”. Funnily enough, the answer is no, but almost that it doesn’t matter – enough things are vulnerable that the problem shifts from a pure technology one to an intelligence one, towards keeping an eye on what’s vulnerable, and keeping tabs on what’s “interesting” – and this leads down a path of philosophical discussions all on it’s own.

Better luck next time – see you all in N1CTF next weekend.

Posted in Bards, Computers, Jesting | Leave a comment

Reversing the e3372 – Completing the Compromise (P711-HILINK Remix)

In my last post, I began detailing the reverse engineering of the Huawei e3372 device. This is a new version of the device, using the P711-HILINK firmware (fingerprinted through a memory dump, I can’t see any visible indicator on the board). Throughout the week, I learned a bit about the Android booting process, and was able to complete the compromise, to get a root shell.

This is clearly a changed firmware from a similar device I acquired last year – on initially UART’ing into the device, no console is presented, and the UART distribution (the L/V/M thing) doesn’t work. Instead, we are presented with an endless scroll of something about “IN drvStartModeGetFlag”.

I began my investigation by pausing the boot process to before the Android kernel had booted, and editing boot arguments:

Unfortunately, this did nothing (nor did init=/bin/sh, removing rdinit, single-user mode and all the trickery I could conceive).

My next approach was to investigate the userland process (suspected userland – investigated via a memory dump from 0xc0000000) which was causing the message loop. The “IN drvStartModeGetFlag” string was from libplatform.so (found through extracting a firmware blob) – specifically, we have a good guess that this code path is from drvStartModeGet (at 0x469C). We can easily nop out of this check:

This exits the crashed process, bringing us to the familiar authconsole interface:

From here, we patch the same 2 authconsole checks as we did to the e5573 to get the EUAP> prompt, and from there, a privileged shell.

I would like to thank the engineering team at Huawei for making this challenge not too easy that I didn’t learn anything, but not too hard that it is impossible. With this approach, we have a way of shelling this device which does not require abusing the update functionality / boot pin trick.

I look forward to seeing you all in Pragyan CTF this weekend.

Posted in Bards, Computers, Jesting | Leave a comment

Notes (rambling) on the E3372 / DIY Supply Adapter for JLink

Over the last few days, I found an old Huawei E3372 device. In the past, I have had limited success compromising this device, but had not been able to independently achieve OS-level access (a shell).

I poked and prodded at this device, and after being still unsuccessful, I figured it would be a good time to desolder the NAND Flash chip to acquire device firmware. Misfortune struck, as (what I assume to be) damage from desoldering rendered the chip unusable, and I was unable to retrieve any meaningful image from it.

With the hot air gun already switched on and whatever toxic desoldering fumes already saturating my room, I pressed on and desoldered everything else for fun. Moments later, bittersweet triumph:

JTAG pads for this device did exist, underneath the SIM card reader. I suspect this was a space-saving measure from Huawei, but this turned out to be a cunning troll: if you wanted to unlock the device via JTAG, you’d need to desolder the SIM card reader and put it back when you were done (or replace it, if the plastic had warped during hot-air desoldering).

I went to the Optus store and purchased a new e3372 device, and wired it up.

The only thing I really needed was some manner of reference voltage for the JLink, to avoid damaging the circuitry. I knew from past experience that this device operated at approximately 1.8V – it didn’t need to be exact, but I should avoid raising voltage levels to 5V.

Initially, I attempted to use the same technique as other Huawei devices, “borrowing” a voltage reference from some other pin. Unfortunately, on this device, it turned out to be unstable – once I connected the “target reference pin”, the voltage reference would drop to zero.

Browsing around, I found a supply adapter available for purchase, which would allow me to set the voltage which the JLink operated at, without a target reference:

Browsing through the documentation available on the Segger website, this looked like a simple voltage regulator on a breakout board. I dug through my massive box of miscellaneous crap, and lo and behold, an open pack of LM317T voltage regulators. I couldn’t remember buying them or using them, but I wondered if I could replicate the functionality of the supply adapter using one of these.

In a nutshell, a voltage regulator can give you a fixed, adjustable output from a variable input. On paper, it looks like this:

R1 and R2 get adjusted to determine which output you want. Our input is the 5V target supply pin on the JLink itself; our output is, naturally, the VTRef pin.

In practice, it looks a little something like this:

To enable the voltage regulator, start JLink, and enter the “power on” command. The target voltage should then jump to approximately 1.8V, which is about what we need to interface with the target, saving me approximately $104 (granted, my version doesn’t come with the power indicator LED, but I’m sure I’ll live without):

Unfortunately, our adventure is not yet over. The “authconsole” bin, which I found in previous adventures (see the notes around the E5572), did not seem to start automatically on this device, nor did I get the option to set the serial console mode with L/V/M/K/etc. Instead, I got some wierd error message (while the device did seem functional): my hypothesis is that this is either a new firmware revision (preloaded onto the device), or some hardware damage may have forced the device into a new state without console access.

Fortunately, the weekend is only half over…

Posted in Bards, Computers, Jesting | Leave a comment

Writeup – Flag Checker 2, Mario Mystery, Envy (Xiomara CTF)

This weekend, I participated in the Xiomara CTF, which has just concluded at the time of writing. I will present some (relatively short) writeups for this CTF below.

Flag Checker 2

This challenge was a web challenge which can be solved locally. The challenge files can be downloaded here.

On opening the HTML file, we are prompted for a password (the flag), which is evaluated with some obfuscated JavaScript. The point value of the challenge did not seem to correspond with the effort of manually de-obfuscating the JS, so I looked for a side channel. I quickly found one, when prettifying main.js:

Here, there is an obfuscated alert() call. On testing in the JS console, this reveals the “You got the correct flag” message. Occam’s razor says that one of the two operands to “!==” is the flag, and a quick test proves us right, and scoring us some easy points:

Mario Mystery

This challenge was presented as an APK, which you can download here.

Initial reverse engineering didn’t reveal anything, and the clue said something about the key being server-side: so my first port of call was the classes.dex file. I put it through dex2jar and jd-gui, which revealed my first clue:

Still, I had no API key. Going through the Java code, I find that the string is loaded from a resource, and MD5’ed:

We can use apktool (apktool d Xiomara_2k18.apk) to extract all the resources from the APK. Browsing through res/values, we find a key:

From here, it is simple enough to MD5 the key, call the API endpoint and grab our flag:


This challenge was presented as a Linux binary, which you can download here.

Upon initial reverse engineering, we don’t see a whole lot – the psuedocode seems to indicate that we’re strcmp’ing two uninitialized variables, some string alluding to a buffer overflow and something indicating fancy binary exploitation (“Try again, you got 0x%08x”).

In the end, all of these turned out to be cunning trolls – the flag was in an unreferenced variable, above the “src” and “s2” strings referenced by the main function:

Thanks to the organisers for putting together this CTF – it was a pleasure to play in, the challenges remained online for the duration of the challenge and there was some good variety without it turning into blind guessing games. See you all in Pragyan CTF (the best part of all of this for me is seeing the same CTF’s come back around, one year on) next weekend.

Posted in Bards, Computers, Jesting | Leave a comment