In the closing hours of JawnCon 0x2, I was making a final pass of the “Free Stuff for Nerds” table when I noticed a forlorn Kindle that had a piece of paper taped to it. The hand-written note explained that the device was in shambles — not only was its e-ink display visibly broken, but the reader was stuck in some kind of endless boot loop. I might have left it there if it wasn’t for the closing remark: “Have Fun!”

Truth is, the last thing I needed was another Kindle. My family has already managed to build up a collection of the things. But taking a broken one apart and attempting to figure out what was wrong with it did seem like it would be kind of fun, as I’d never really had the opportunity to dig into one before. So I brought it home and promptly forgot about it as Supercon was only a few weeks away and there was plenty to keep me occupied.

The following isn’t really a story about fixing a Kindle, although it might seem like it on the surface. It’s more about the experience of working on the device, and the incredible hacking potential of these unassuming gadgets. Whether you’ve got a clear goal in mind, or just want to get your hands dirty in the world of hardware hacking, you could do far worse than picking a couple of busted Kindles up for cheap on eBay.

If there’s a singular takeaway, it’s that the world’s most popular e-reader just so happens to double as a cheap and impressively capable embedded Linux development environment for anyone who’s willing to crack open the case.

Getting Connected

We start with what’s essentially Hardware Hacking 101: the hidden serial debug port. It’s the sort of thing you learn to look for when taking apart a new gadget, and unsurprisingly, it’s also at the heart of Kindle hacking. While there’s plenty of software modifications you can do depending on the age and version of your particular Kindle, opening up the case and tapping into the serial port is always the most direct way to gain access to the system.

From my research, every Kindle (with the possible exception of the very latest models from the 2020s) have an unpopulated serial port on the board. In the case of this Kindle Paperwhite 2 from 2013, it’s even labeled. I simply soldered on some jumper wires and ran them out to a pin header to make connecting to it a little less fiddly. The only thing to watch out for is the voltage; it seems that the serial port on the majority of Kindles is 1.8 V, and connecting up a higher voltage USB-serial adapter without a level shifter could release the Magic Smoke.

With the hardware connected and my favorite serial communications tool running, it was easy to see what ailed this particular Kindle. As evidenced by the final few lines of the kernel messages, a failure of one of the voltage regulators in the MAX77696 — a power management IC designed specifically for e-ink readers — was preventing the driver module from loading fully. This in turn was triggering a reboot, presumably because some sort of watchdog routine was in place to bail out if any critical hardware issues were detected.

On the Hunt

Coming from the “normal” Linux world, the solution seemed easy enough. Since the screen was toast anyway, all I needed to do to get the Kindle booting was to prevent the kernel module from loading. That way I could at least use it for something, perhaps an energy efficient minimalist server.

But according to the MAX77696 datasheet, the chip was responsible for quite a bit more than simply driving the e-ink panel. If I pulled the kernel module entirely, there was a good chance I’d also lose features like the real-time clock and the ability to read the battery voltage as well. So I decided to change tactics: rather than keeping the driver from loading, I’d take out the watchdog that was forcing the system to reboot. But where was it?

Amazon makes it easy to manually download the latest firmware for each member of the Kindle family, and the aptly named KindleTool lets you manipulate them. In this case I used the extract function to pull out the root filesystem image, which I could then locally mount as a basic EXT3 volume.

That was refreshingly straightforward, but unfortunately didn’t get me where I needed to go. Using grep to search all the files within the filesystem for the string “failed to load eink driver” showed no hits. If the watchdog wasn’t in the root filesystem, then where was it?

Unpacking the firmware update with KindleTool also got me the kernel image, and running Binwalk against it showed there was a compressed filesystem at 0x466C. I reasoned this must be an initramfs — essentially a minimal Linux system that lives in RAM and gives the kernel a place to work as it brings up the rest of the system. If the system has some self-check capability, it’s reasonable to assume that’s where it lives.

After drilling down a few times with Binwalk’s extract function, I was able to get to the contents of the initramfs. Sure enough, another search for the error message revealed our sentinel: /bin/recovery-util.

New Kernel, Who Dis?

I had considered trying to simply remove the recovery-util program from the kernel image, but since I wasn’t 100% sure how the whole watchdog system functioned, there was no guarantee that would have worked without more trial and error. So, emboldened by how well this was all going for me so far, I took the nuclear option and decided to rebuild the kernel with my own initramfs.

It’s here that the Kindle software environment, and the community around it, really started to shine. Once again, Amazon made it ridiculously easy to get the source code for the exact firmware I was working with, and the community provided an actively maintained toolchain to build it with. A little more searching even pulled up some pre-compiled builds that were ready to use.

Actually building the kernel for the Kindle was essentially the same process as doing it on my desktop computer, with the notable addition of supplying the location of the cross compiler into each make command. But if I ever got off track, there were plenty of write-ups online to reference. I even found one that went over building a custom initramfs with BusyBox that doesn’t include any of Amazon’s programs.

But perhaps the best part was that, once I had compiled Amazon’s modified kernel and built my initramfs, installing it on the Kindle was as simple as using a modified version of Android’s fastboot command. There were no cryptographic hoops to jump through, you just give it the new kernel and away it went. It’s my understanding that newer Kindles might not be so understanding, but with at least the hardware of this vintage, there’s nothing stopping you from doing whatever you want.

Pocket Penguin Playground

With the source code, tools, and knowledge floating around out there, I was able to build my own kernel and initramfs that lets me boot into a full Linux environment on what was previously a non-functional Kindle. There are a few things I haven’t gotten to work yet, but I believe that’s largely because I’m still using the root filesystem provided by Amazon.

Now that I know how easy it is to work with Linux on the Kindle, I’m looking to push further and put together my own stripped-down environment without any of Amazon’s frameworks installed. Given how ridiculously cheap early Kindles are on the second hand market — especially if they have a busted screen — there are all sorts of tasks that I could see them performing if I had a solid base to build on.

Make no mistake, I’m greatly appreciative of the fact that we now have mature single-board computers like the Raspberry Pi available for a reasonable cost. But taking what’s essentially consumer e-waste and turning it into a useful platform for learning and experimentation is the true hacker way. So whether you’ve got a Kindle collecting dust somewhere at home, or end up grabbing a few off of eBay for a song, I invite you to bust out the USB-serial adapter and start exploring.

Learn coding, electronics, and real-world STEM skills by assembling and programming a working smartwatch.

The post This Buildable Smartwatch for Budding Engineers Is Just $85 appeared first on TechRepublic.

By Kim Crawley

The Synack Red Team is made up of hundreds of the best pentesters and tech practitioners in the world, hailing from countries across the globe with a variety of skills, who coordinate their efforts to conduct pentesting engagements and other security tests for Synack’s clientele. 

When a large group of ethical hackers work together, they can find more exploits and vulnerabilities than traditional pentesting, which usually consists of two people with two laptops who conduct on-site testing over two weeks. 

But when you have security researchers working as a collective, they are smarter, more adept and more creative. As cyber threats become increasingly sophisticated, the Synack Red Team (SRT) has the advantage of a diverse and holistic talent pool to take on the challenge. 

Not only do the SRT bring a fresh perspective to pentesting, SRT members also help alleviate the widely felt skills gap in cybersecurity. 

>> For an in-depth look at the SRT’s diversity of skills, read our white paper “Solving the Cyber Talent Gap with Diverse Expertise.” 

Whether you’re looking to take your organization’s security testing to the next level or a curious thinker who aspires to have a pentesting career, SRT members gave useful advice and explained how it all works. 

SRT Reduces Noise

Özgür Alp, from Turkey, had a lot of pentesting experience prior to joining the SRT, but working with the growing community of 1,500 security researchers taught him the power of collaboration at scale. 

“When I started at Synack, I had four years of experience as a pentester in a multi-global company,” Alp said. “After joining Synack and working as a full-time SRT member, I see that here we are focusing not only on the theoretical bugs but also trying to find the critical ones that matter and are exploitable within the real world scenarios.”

The gamification of vulnerability finding that happens on the researcher side of the platform means that you get their full attention and focus on finding vulnerabilities that matter. The more critical the vulnerability, the higher the payouts and recognition Synack rewards them with.

“I’m starting to focus on more complex scenarios, since you have time to work for that. For example, I actually learn what a theoretical bug could really mean in terms of business impact,” Alp said.

Applying Prior Cyber Knowledge and Experience 

Emily Liu, like many SRT members, works on the Synack platform part-time. Many SRT already work in a cybersecurity role and use the opportunity to apply the knowledge they’ve learned from their day-time job to their Synack role and vice-versa. 

“It sharpens my skills by allowing me to practice finding different vulnerabilities on real targets,” Liu said. “The whole process of doing work for SRT has taught me to think more creatively and to be more persistent, because you can find bounties so long as you put in the effort.”

But the work of the SRT can only be done with an “adversarial” perspective, from the outside-in. Büşra Turak explained the difference between being an SRT member and an employee or in-house consultant. 

“It is usually enough to show the existence of a finding in consultancy firms that provide pentest services. But we don’t do that here,” she said. “We show how much we can increase the impact of the finding or we need to show how the vulnerability is exploited.”

Taking the “Red Team” to the Next Level

In terms of bug bounties, red teaming and pentesting, Synack’s formula for vetting, monitoring and developing its SRT members puts them in another class of security researcher. SRT members are good at what they do from the start, and they’re also given immediate feedback for continuous improvement.

SRT member Nikhil Srivastava talked about what working with SRT has taught him.

“Initially, my reports were not up to the mark when I had just got into bug bounties. It was sent back to me multiple times for revision,” he said. “But, with the introduction of the Synack Quality Rule, we had to keep challenging ourselves with each new target launch—not only to find vulnerabilities but also to write a quality report that stands out from reports of other SRT members and is clearly understood by the clients. This helped me in leveling up.”

No matter if you’re able to get into the weeds of every vulnerability, a Synack report will thoroughly explain the potential exploit. 

“I started reporting vulnerabilities that could precisely illustrate the impact even to a non-technical person and could be easily replicated by them,” Srivastava said.

If you’re curious about what it takes to join the Synack Red Team, start your journey here. To better understand how the SRT can solve your struggle with the cyber talent gap, read our latest white paper.

The post How the 1,500+ Synack Red Team Members Solve Your Most Critical Cybersecurity Vulnerabilities appeared first on Synack.