How to Disassemble Vita Game Cartridges

A hacker named katsu recently released a method for dumping Vita games. As a developer, I am completely against piracy, but as a reverse engineer I can’t shy away from taking apart perfectly working devices. However, most pictures I see of Vita game carts taken apart show the game cart casing damaged beyond repair or completely destroyed. I managed to take apart a game cart and put it together with no obvious signs of damage, and I thought I would share my (simple) method here.

Photo Feb 16, 7 48 07 PM

 

If you take a look at the top right or left corner of the game cart, you can see a line of where the two halves of the plastic was glued together. Locate the upper left corner and, with a sharp knife, push the blade into the line on the corner until you have a small dent. Then, move the knife downwards and wiggle the knife until you loosen the glue for the entire left side of the cart. Then keep moving the knife down and when you hit the bottom of the cart, turn and lose about half the bottom edge of the cart. Now you can use your fingers to spread the two halves apart (but be careful not to use too much force and tear the glue from the other two edges), and you can either shake the memory chip out or use a pair of tweezers.

Photo Feb 16, 7 42 47 PM

 

If you were to follow katsu’s pinout, you need to solder to the copper pads. A trick for doing so is to first flux up the points and then melt a pea-sized blob of solder in middle of all the points. Then take your iron and spread the blob around until all the pads are soldered up. Then just make the the remaining blob is not on top of any copper and you can easily remove it.

Photo Feb 16, 8 29 57 PM

 

Then you can solder wires onto the points to your heart’s content. After you’re done with everything, you can easily put the memory chip back into the casing and there is enough glue to keep the two halves of the case together (along with the memory chip). You can then continue to play the game.

Pinout for Vita game cart. Credits to katsu.

If you were to follow the pinout, you can see that it appears to be a standard NAND pinout (not eMMC and not Memory Stick Duo). I have not tested this, but I believe this means you can use NANDWay or any other NAND dumping technique (there’s lots for PS3 and Xbox 360) provided you attach to the right pins. I suspect that the Vita communicates with the game cart through the SD protocol with an additional line for a security interface, but that is just speculation. If that were the case, having one-to-one dumps would not allow you to create clone games. Regardless, I will not be looking too much into game carts because they are so closely tied with piracy.

Updates on the Vita Hardware Hacking project

After a week of trying to dump the eMMC (spoilers: didn’t happen yet), I’ve decided to post this update about things I’ve tried to do (and how I tried to do it) and where the money is going to.

Supplies

I had two Vita logic boards. The first one, which I removed the SoC and eMMC to find the trace points (shown previously), came from eBay. The second board came from a Vita with a broken screen generously donated by @Amxomi. I also bought a professional rework station, the X-Tronic 4040 which was paid partially by your donations (I returned the heat gun) and partially thanks to wololo. For wiring, the thinnest wire I could find is enamel-coated magnet wire. For soldering the wires, I got 60/40 Rosin solder and a Rosin flux pen.

Attempt One

The first thing I did was remove the EMI shield base blocking the test point resistors. With the reflow station’s hot air gun, it was much easier than the heat gun I used last time. Next I warmed up my soldering skills by hooking wires up to a microSD to SD card adapter. My plan was to attach the wires to the test point and plug the SD card into a SD card reader. To expose the copper in the enamel-coated wire, I melted a blob of solder and kept it on the tip of the iron at 400C. Then I dipped the tip of the wire into the liquid solder, which both coats the tip of the wire with solder and also removes the coating. It’s a neat trick that I used all the time throughout the rest of the ordeal.

Then I brushed the pins of the microSD adapter with flux and quickly melted a small blob of solder on each pin. Then with a pair of tweezers, I held each wire next to the pin, and as soon as it is heated, the small bit of solder on the wire joins with the blob on the pin and they connect.

It gets much harder connecting the other end. There is very little exposed solder on the tiny resistors, and it is very hard to add more because you might accidentally short circuit two adjacent pads. I made sure there is a bit of solder on the end of the wire using the trick. Then I held the end of the wire steady with the tweezer while tapping it with the iron. It takes many tries for it to stick on, and many times when trying to attach the neighboring pads, the heat from the iron loosens the other wires. In addition, accidentally bumping into the wire causes enough stress to rip the solder off the resistor (because there is so little solder), so I just taped everything to a piece of cardboard. I also can’t test if my joints are correct and not shorted with any other joints because of how small and close everything is.

After a couple of hours, the wires are soldered to the points but there are a couple of problems. First, as mentioned, I couldn’t test the correctness of my connections. Second, I don’t know if in the process of soldering to the tiny resistors, I damaged any resistors and if so, would it still work. Third, I never found a test point for Vdd because for some reason, Vdd shorts to Vss/Ground on my first board. As expected, after plugging the microSD adapter into a reader into the computer, nothing shows up. Because there could be so many problems, I removed all the wires and started over.

Attempt Two

First, I located a test point for Vddf (Vdd is power to the eMMC controller while Vddf is power to the actual NAND chip). My hypothesis is that the same power source that powers Vddf also powers Vdd (although the Samsung documents recommends against this). This point is on top of the tiny resistor to the left of the audio jack.

Next, I decided to remove all of the 150ohm resistors on the test points in order to get more solder surface area. Looking at the eMMC testpoints picture from last time, it’s important to note that the pad on the left of each resistor is the one coming from the eMMC while the pad on the right of each resistor is the one going to the SoC. The resistors themselves may be for current limiting or noise removal. Removing them is as simple as pointing at it with the hot air gun set to 380C for half a minute and then using tweezers to to remove them.

I also found it easier to solder wires directly to the SD card reader instead of to an microSD to SD card adapter. I first verified that the card reader still works and that my wires are not too long by soldering the other end of the wire directly to an old 128MB SD card. After verifying, I removed the wires from the SD card and attached them to the now exposed test points.

Unfortunately, it still didn’t work. The computer sees the SD card reader but believes no card is inserted. Again, there could be any number of problems including (still) bad soldering, Vdd not receiving power, or even read protection in the eMMC.

Attempt Three

Next I made another attempt to find Vdd. The problem is that my multimeter shows a short from Vdd to Vss. This means that Vdd is somehow shorted to ground either because I broke something with all the heat and bad soldering or because that is by design (which I don’t think is true because all documents I read say that you need to power Vdd for the eMMC controller to work). I thought maybe I can experiment by sending test voltages through various locations on the first logic board (the one with the chips removed) and see if I get a voltage drop in the Vdd pad. I used an old broken MP3 player as my voltage source (since it was just laying around and I didn’t want to buy a power supply, rip open any working cable/device, or solder to a battery). I attached the positive end to a pointed screwdriver and the negative end to the Vita’s ground. Then I attached one probe of my voltmeter to the same ground. Then with the screwdriver in one hand and the voltmeter probe in the other hand, I tried to send voltage through every location on the board. Unfortunately, the only response was sparks on capacitors here and there but no response in Vdd.

Back to the second Vita, I tried to attach the battery and charger and turned it on. At first, I got excited and saw a voltage drop on the eMMC’s decoupling capacitor (meaning there’s power going to the eMMC). However, after going back and reattaching the wires, I could no longer reproduce the result. In addition, the power light no longer responds to the power switch. I believe that I shorted something and the first time I powered it on, it destroyed some component; so the next time I attempted to power it on, it fails before even attempting to power the eMMC.

Regardless, I tried to reattach all the wires with better soldering on the assumption that my only problem is still the bad soldering (likely not true). Being the fourth or fifth time doing this, I am getting better at soldering these extremely tiny points. My trick was to first align the wire to the board and then using the tweezer, make a 90 degree bend on the end of the wire. This makes the end of the wire the same length as the original resistors. Then I quickly dip the end in solder, flux the board, and attach the wire to two pads instead of one. This makes a stronger connection. Even though I did a much better job and soldering the test points, I still could not get anything to show up on my computer.

Attempt Four

Now that I have experience in soldering tiny points, I made an attempt at soldering directly to the eMMC removed from the first Vita. However, after a quick test (nothing shows up on the computer), I didn’t look any farther because I believe that the eMMC must be part of a circuit of capacitors and resistors in order for it to work (and not break the chip). All documents I’ve read supports this.

I also made yet another attempt at resoldering to the board again and still no luck. At this point, I believe that either I still am not powering Vdd correctly, or I broke the eMMC at some point. I also suspect that perhaps my SD card reader does not support the Samsung eMMC or that it is not being initialized correctly.

What’s Next

I still haven’t given up. I will continue to try resoldering the points. I still want to find a way to surely power Vdd; I bought another Vita from eBay because I believe the second Vita is now broken. I also ordered a eMMC socket with the last of the usable donations, but it will take at least a month to arrive from China. There’s also the possibility that the eMMC does something unsupported by my SD card to USB adapter and I want to do some raw signal interaction with an Arduino. If you want live updates of progress as I’m working, join #vitadev on EFnet.

Removing the CPU and NAND from PSVita

Thanks again to everyone who helped fund this project! This is the first part of the long journey into hardware land. I bought a non-working Vita logic board from eBay, which arrived yesterday, packaged like a freeze-dried snack.

As delicious as it looks.

As delicious as it looks.

In order to locate the trace from the eMMC (aka the NAND), my plan was to take a broken logic board and remove the eMMC chip and use the exposed pads and trace it to a test point or something. Then take another Vita logic board (this time with the eMMC still attached) and solder wires to the test point and dump it with an SD card reader or something (as eMMC uses the same interface as SD cards). This is a complicated plan, but it’s necessary because I am not professional enough to be able to remount the eMMC (which is a tiny fine-ball-grid-array (FBGA) chip) once the trace is found.

First, you have to remove the EFI shields. The actual shields are fairly easy to remove; they are clicked into the base, and all it takes is a little pry from all sides (careful not to destroy any components near-by). However, the hard part is getting the surface mounted base off. Removing the base is recommend because it allows easier access to the eMMC, and if the test point happens to be close to the chip, it would be impossible to solder with the base in place.

Before starting, make sure the board is completely stable (since a lot of prying will be performed). I chose to tape the board to a unwanted book (which had burnt marks at the end; don’t know if the heat gun reaches the autoignition temperature, so in hindsight that was not a good idea) but having clamps would be a better solution. When using the heat gun, keep it fairly close to the board (about an inch off) and on the low setting.

To remove the base, heat up the board with a heat gun (to prevent too much expansion in one area) and direct the heat at the edge of the base near the eMMC. Wave the heat gun slowly across the entire edge while using the other hand to try to pry the base off with a pointy-metal-apparatus (scientific term; perhaps a flat head screwdriver will do). As the base peels off, move the heat gun to the next position where the base is still attached and repeat until the entire base is off. Be careful not to move the board too much or accidentally touch any of the tiny components all around because even though the board will not be used anymore, you don’t want to destroy a potential path from the eMMC.

Freed from its Faraday cage

Freed from its Faraday cage

To remove the actual eMMC chip, keep the heat gun directed at the chip for a while, then use your pointy device to try to pry it off. Use a bit of force but not extreme force and be slow with the prying. This is because even though the solder below melts fairly quickly, the chip is held in place with some kind of glue (most likely so during the manufacturing process, when surface mounting the other side of the board, the chip doesn’t fall off). If you pry too hard or too quickly, you may rip some unmelted solder off or (as in my case), actually rip off the solder mask below the glue.

Notice the burnt paper underneath. Don't try this at home.

Notice the burnt paper underneath. Don’t try this at home.

You can repeat the process for the SoC if you wish, although more care should be applied here since there are so many tiny components near the chip.

I was a bit better this time and didn't strip any solder mask.

I was a bit better this time and didn’t strip any solder mask.

Congratulations! You have destroyed the Vita beyond the possibility of recovery.

Before the destruction of a great piece of engineering

Before the destruction of a great piece of engineering

Vita with those useless chips removed

Vita with those useless chips removed

In hindsight, I should have used a hot air rework gun instead of a paint-stripping heat gun, as someone in the comments suggested last time. Then, maybe it wouldn’t look so bad. But luckily, it seems that all of the components are still attached to the board, so tracing wasn’t so hard. The bad news is that after tracing, it seems that the only exposed connection I could find from the data pins of the eMMC to the SoC was in the pile of tiny resistors next to the SoC. Tune in next time to see more amateur mistakes and destruction.

Unlimited Backgrounding on iOS

Since iOS4, developers have the ability to perform background tasks with some limitations. Background tasks must fit one of the five different categories for background supported apps. Music and streaming apps can be backgrounded as long as they play music. Newsstand apps can wake once a day to download updates. Location aware apps can wake up once in a while to update their position. VOIP apps can have one socket (I found out the hard way that the one socket does not include listener sockets) connected in the background. General apps can request up to 10 minutes to finish some task. While this is enough for most backgrounding purposes, sometimes we need backgrounding for more advanced tasks. Specifically, I wanted to write a HTTP proxy server that runs on the device (in the future, this proxy server will work as an ad-blocking proxy) in the background. I will show you the steps of making this work. Please note that Apple will certainly reject any app that abuses their backgrounding policy so doing so would only be useful for personal and enterprise uses.

So how are we going to abuse the iOS background policy? We are going to declare our app as a background music player but not play any music. Sounds simple right? Well, in hindsight it is, but there’s some subtle tricks I had to discover to get it all working. Let’s go through this step by step…

First make sure your app has, in “Capabilities”, Background Modes turned on and “Audio and AirPlay” enabled. Also make sure you’re linking with “AVFoundation.framework.”

In our demo app, we will have one button that says “Enable Background” that, when tapped, will keep our app running even if the user switches apps. We also have a NSThread will will keep logging to show that it is running even in the background.

First create your silent music file. I had success with a one-second MP3 file of silence. The audio file does not have to be silent, but why scare the user with a random audio file? Add this to the “Supporting Files” category.

Add a property to the View Controller that will hold the silent audio player.

@property (nonatomic, strong) AVPlayer *player;

Now, you should set up the audio session. I chose to do this in viewDidLoad of my view controller of the single view in the demo app.

NSError *sessionError = nil;
[[AVAudioSession sharedInstance] setCategory:AVAudioSessionCategoryPlayback withOptions:AVAudioSessionCategoryOptionMixWithOthers error:&sessionError];

The category AVAudioSessionCategoryPlayback is one of the few categories that allow for backgrounding. The option AVAudioSessionCategoryOptionMixWithOthers will make sure your silent audio won’t stop any currently playing background audio and also make sure that when the user plays music in the future, it won’t kick off your background task. A good developer will also check the return values and sessionError, but I’m not a good developer.

AVPlayerItem *item = [AVPlayerItem playerItemWithURL:[[NSBundle mainBundle] URLForResource:@”silence” withExtension:@”mp3″]];
[self setPlayer:[[AVPlayer alloc] initWithPlayerItem:item]];

Now create the actual player item for your silent audio file. If you are embedding your audio file a different way, feel free to adapt this to do so. No trickery here.

[[self player] setActionAtItemEnd:AVPlayerActionAtItemEndNone];

Here’s the trick; this makes sure that the audio player is kept active after playing your sound file. The alternative is to keep looping a silent track, but why waste more CPU cycles (and battery)?

Now, whenever you wish to keep the app in the background, just call

[[self player] play];

And your app will keep working even after the user switches the app. In my case, the HTTP proxy server was still working after I left the iPad in sleep mode overnight (with the charger connected of course).

Here is the sample code: Limitless Background (863)

Unlocking T-Mobile 4G Hotspot (ZTE MF61): A case study

So, I have one of these MiFi clone from T-Mobile and want to unlock it to use on AT&T (I know that AT&T 4G/3G isn’t supported, but I thought maybe I could fix that later). The first thing I tried to do was contact T-Mobile, as they are usually very liberal concerning unlock codes. However, this time, T-Mobile (or, as they claim, the manufacture) isn’t so generous. So I’ve decided to take it upon myself to do it. I will write down the entire procedure here as a case study on how to “reverse engineer” a new device. However, in no way do I consider myself an expert, so feel free to bash me in the comments on what I did wrong. Also, I have decided against releasing any binaries or patches because phone unlocking is a grey area (although it is legal here), but if you read along you should be able to repeat what I did, even though I will also try to generalize.

Getting information

The hardest part of any hack is the figuring-out-how-to-start phase. That’s always tricky. But… let the games begin.

-Wheatley, Portal 2

So before we can do anything, we need to know what to do. The best place to begin is to look at the updater. A quick look at the extracted files, we find that the files being flashed have names such as “amss.mbn”, “dsp1.mbn”, and such. A quick scan with a hex editor, we see that the files are unencrypted and unsigned. That’s good news because it means we have the ability to change the code. A quick Google search shows us that these files are firmware files for Qualcomm basebands. Now, we need to find more information on this Qualcomm chip. You may try some more Google-fu, but I took another path and took apart the device (not recommended if it’s any more complicated). In this case, I found that we are dealing with a Qualcomm MDM8200A device. Google that and you’ll find more information such as there are two DSP processors for the modem and on “apps” ARM processor (presumably for T-Mobile’s custom firmare, and is what you see as the web interface). We want to unlock the device, so I assume the work is done in the DSP processor. That’s the first problem. QDSP6 (I found this name through more Google skills) is not a supported processor in IDA Pro, my go-to tool, so we need another way to disassemble it.

Disassembly

Some more Googling (I’m sure you can see a pattern on how this works now) leads me to this. QDSP6 is actually called “Hexagon” by Qualcomm and they kindly provided an EBI and programmer’s guide. I guessed from the documents that there is a toolchain, but no more information is provided about it. More searching lead me to believe that the in-house toolchain is proprietary, but luckily, there is an open source implementation that is being worked on. Having the toolchain means that we can use “objdump”, the 2nd most popular disassembly tool [Citation Needed]. So, it’s just a matter of sending dsp1.mbn and dsp2.mbn into objdump -x? Nope. It seems that our friends at ZTE either purposely or automatically (as part of the linker) stripped the “section headers” of the ELF file. I did a quick read of the ELF specifications and found that the “section headers” are not required for the program to run, but provides information for linking and such. What we did have was the “program headers”, which is sort of a stripped down version of the section headers. (Program headers only tell: 1) where each “section” is located in file and where to load it in memory, 2) is it program or data?, 3) readable? writable?, while section headers give more information like the name of each section and more on what the program/data section’s purpose is). What I then did is wrote my own section headers using the program headers as a guide and made up the names and other information (because they are not used in the actual disassembling anyways) with a hex editor. Then I pasted my headers into the file, changed some offsets, and objdump -x surrendered the assembly code. 180MB worth of it.

Assembly

So we have 180MB worth of code written in a language that could very well be greek. Luckily, as I’ve mentioned earlier, Qualcomm released a document detailing the QDSP assembly language and how it’s used. Most likely, you would be dealing with a more “popular” processor like ARM or x86 and would have access to more resources. However, for QDSP6/Hexagon, we have two PDF documents and that is basically the Bible that we need to memorize. I then spend a couple of hours learning this new assembly language (assembly isn’t that hard once you embrace it) and figured out the basics needed to reverse engineer (that is: jumps, store/loads, and arithmetic). Now, another problem arises. We have literally 3 million lines of assembly code with no function names, no symbols, and no “sections”. How do we find where the goal (the function that checks the NCK key and unlocks the device accordantly) without spending the next two years decoding this mess? Here, we need to do some assumptions. First, we know   (through Google) that the AT modem command for inputting the NCK key is AT+ZNCK=”keyhere” for ZTE devices. So, let’s look for “ZNCK” in the hex editor of dsp1.mbn and dsp2.mbn. (If you are not as lucky and don’t know what the AT command is, I would put money that the command will contain the word NCK, so just search that). In dsp2.mbn, we find a couple of results. One of the results is in a group of other AT commands. Each command is next to a 4-byte hex value and a bunch of zero padding. I would guess that it is a jump table and the hex values are the memory locations of the functions to jump to. Doing a quick memory to file offset conversion (from our ELF program header), we locate the offset in our disassembly dump to find that it starts an “allocframe” instruction. That means we are at the beginning of a function so our assumptions must be right. Now, we can get to the crux of the problem, which is figuring out how the keycheck works.

Mapping out the functions

We now know where the function of interest starts, but we don’t know where it ends. It’s easy to find out though, look for a jump to lr (in this case for this processor, it’s a instruction to jump r31). We start at the beginning of the function and we copy all the instruction until we see a non-conditional jump. We paste the data into another text file (for easier reference). Then we go to the next location in the disassembly (where it would have jumped to) and copy the instruction until we see another non-conditional jump, and then paste them into the second text file. Keep doing this until you see a jump to r31. We now have most of the function. Notice I kept saying “non-conditional” jumps. That’s because first, we just need the code that ALWAYS runs, just to filter out stuff we don’t need. Now, we should get the other branches just so we have more information. To do this, just follow each jump or function call in the same way as we did for the main function. I would also recommend writing some labels like “branch1″ and “func1″ for each jump just so you can easily locate two jumps to the same location and such. I would also recommend only doing this up to three “levels” max (three function calls or three jumps) because it could get real messy real quick, and we will need more information so we can filter out un-needed code, as I will detail in the next section.

Finding data references

Right now, we are almost completely blind. All we know is what code is run. We don’t know the names of functions or what they do, and it would take forever to “map” every function and every function every function calls (and so on). So we need to obtain some information. The best would be to see what data the code is using. For this processor (and likely many others), a “global pointer” is used to refer to some constant data. So, look for references to “gp” in the disassembly. Searching from the very beginning of the program, we find that the global pointer is set to 0×3500000, and according to the ELF headers, that is a section of the dsp2.mbn file at some file offset. In the section we care about, look for references to “gp” and use the offsets you find to locate the data they refer to. I would recommend adding some comments about them in the code so we don’t forget about them. Now, the global pointer isn’t everything, we can have regular hard-coded pointers to constant areas of memory. Look for setting of registers to large numbers. These are likely parameters to function calls that are too big to be just numerical data and are more likely pointers. Use the ELF header to translate the memory locations to file offsets. In this case (for this processor), some values may be split into rS.h and rS.l, these are memory locations that are too “large” to be set in the register at once. Just convert rS.h into a 16 bit integer, rS.l into a 16 bit integer (both might require zero padding in front), then combine them into one 32 bit integer where rS.h’s value is in front of rS.l’s value. For example, we have: r1.h = #384; r1.l = #4624. That will make r1 == 0×1801210. You should also make some comments in the code about the data that is being used. Now, predict standard library calls. This may be the hardest step because it involves guessing and incorrect guessing may make other guess more wrong. You don’t have much information to go by, but you know 1) the values of some of the data being passed into function calls, and 2) library calls will usually be near the start of the program, or at least very far away from the current function. This will be harder if the function you are trying to map is already near the beginning of the program. The function I’m mapping is found at 0xf84c54, and most function calls are close to it. When I see a function call to 0xb02760, I know that it might be a library call. 3) Some of the more “common” functions and the types of parameters they accept. You don’t need to figure out all of the library calls, just enough to get an idea of what the code is doing so you don’t try to map out these functions (trying to map out strcpy, for example will get messy real quick). For example, one function call, I see is taking in a data pointer from a “gp” offset, a string that contains “%s: %d”, and some more data. I will assume it is calling fprintf(). I see another function is being called many times throughout the code, and it always accepts two pointers where the second one may be a constant and a number. I will assume it is calling memcpy().

Translating

This may be the most boring part. You should have enough information now to try to write a higher language code that does what the assembly code says. I would recommend doing this because it is much easier to see logic this way. I used C and started by doing a “literal” transcription using stuff like “r0-r31″ as variable names and using goto. Then go back and try to simplify each section. In my process, I found that how the unlock key is checked is though sort of a hash function. It takes the user input, passes it through a huge algorithm of and/or/add/sub of more than 1000 lines and takes the result and compares it to a hard coded value in the NV ram (storage area for the device). Here, I made a choice to not go through and re-code this algorithm for two reasons. First, it would be of little use, as the key check doesn’t use a known value like the IMEI and relies on a hard coded value in the NV ram that you need to extract (which a regular user might have trouble doing). Second, after decoding it, we would have to do the algorithm backwards to find the key from the “known value” in the NV ram (and it could be that it would be impossible to work backwards). So I took the easy way out and made a 4-byte patch in where I let the program compare the known value to itself instead of to the generated hash from the input and flashed it to the device. Then I inputted a random key, and the device was unlocked.

Now, remember at the beginning I said the code was unsigned? Because of that I could easily have reflashed the firmware with my “custom” code. However, if your device has some way of preventing modified code from running, you may have no choice but to decode the algorithm.

Installing Windows 8 Developer Preview (8102) on a USB Drive (Windows To Go/Portable Workspace)

This really isn’t some technical or hard to do thing, but it’s a cool little trick I found that I haven’t seen mentioned before. If you don’t know what “Windows To Go” (previously “Portable Workspace”), watch this video from the Build 2011 conference. Basically, it allows you to install a full copy of Windows 8 onto a USB drive/external hard drive and use it on any computer that supports USB booting. Your settings, files, programs, etc go where-ever you go. The feature is in Windows 8 (and the developer preview), but the program to make the drive is not. Luckily, an old leaked build has the program, but you can’t just copy and paste it, it won’t run. Instead, follow the directions below to get Windows 8 installed to a USB drive. (I used a virtual machine to do the following, therefore I did not need to burn any DVDs. I will give the directions assuming you’re using a real computer though).

Requirements:

  • Windows 8 Developer Preview burned to a DVD (unless you’re using virtual machine)
  • Windows 8 M1 build 7850 burned to a DVD (unless you’re using virtual machine)
  • 16GB flash drive or external hard drive (or larger)
Directions:
  1. Install Windows 8 M1 build 7850. (I tried just copying pwcreator.exe and running it on a later build, but it didn’t work.)
  2. Open the start menu and type in “pwcreator.exe” and press enter. Alternatively, find and open C:\Windows\System32\pwcreator.exe
  3. Choose your USB drive and continue.
  4. Insert the Windows 8 M1 build 7850 DVD again and continue.
  5. Before starting the build process, take out the Windows 8 M1 build 7850 DVD and insert your Windows 8 Developer Preview build 8102 DVD.
  6. Continue and allow the process to finish.
I tested it with the x86 version of the Developer Preview, so I don’t know how well or if it will work with the x64 build. When you are asked to activate Windows, you can skip it or enter one of the keys found in the Developer Preview DVD under D:\Sources\product.ini (assuming D: is your DVD). I haven’t figured out which key to use yet.
Also, the requirements in pwcreator.exe states that you need a 16GB USB drive. However Windows only really need 12GB to install. I have a 16GB flash drive that shows up as 15GB and it wouldn’t work. I used GParted in Ubuntu to copy the partitions from a larger USB drive over after creating the image and it works fine. Just a tip.

Recovering a formatted or corrupt Kindle 2

One day, while playing around with a Kindle 2, I accidentally deleted the /lib folder. Oops. Now, no command beyond “ls” and “rm” work. If this was a computer, I could have simply inserted a installation DVD and copied the files over, but this was an eBook reader, and I was in for a world of pain. This was a month ago, and I’ve finally recovered the Kindle. I’m posting what I did online to save anyone else who’s in the same boat a ton of time. This tutorial is only designed for the Kindle 2, but it MAY work for the DX. It will NOT work for the Kindle 3, but directions should be similar.

 

First

If you’ve think you “bricked” your Kindle, don’t panic yet. There could be a easy solution. Chances are, if you can see the startup progress bar loading, the solution should be easier (although I can’t tell you exactly what your problem is). I would follow Amazon’s troubleshooting directions first. Only proceed if you are absolutely sure nothing else can be done.

Overview

Here’s what you’ll need

  1. TTL to RS232 or USB connector. I used this one. For that, use the jumper on pin 1 and 2 on the side (with the three pins, pin 1 is towards the USB port). Connect Kindle Tx -> Tx, Rx -> Rx, GND -> GND, VDD -> VDD
  2. Windows with HyperTerminal (I tried Kermit on Linux, but it couldn’t send files. HyperTerminal is the only program I’ve tested that works sending files to the Kindle)
  3. Linux or Unix-based computer with “dd” and “ssh”
  4. My custom recovery kernel which allows jailbreak signed recovery packages and exporting MMC0 without a password. If you want to know how I’ve made it in technical details, see the appendix.

Here’s what we’ll be doing:

  1. Attaching the recovery port
  2. Flashing the custom patched recovery kernel
  3. Obtaining a backup of Kindle system files
  4. Restoring your Kindle

Attaching the recovery port

First open up the Kindle 2 to reveal the PCB board. You should remove both the metal casing and the white plastic with all the screws. On the top, to the left of the headphone jack, you should see four pads labeled J4. Either solder (recommended) or tape (make sure it isn’t lose!) four wires to these pads. The order of these ports (left to right, where left is towards the volume switch) are: VDD, Rx, Tx, GND. Connect these lines to your TTL adapter and connect the adapter to your computer.

Flashing the custom patched recovery kernel

Open up HyperTerminal, and connect to your adapter. Make sure to click “Configure” and fill in the settings. The settings are: BPS: 115200, Data bits: 8, Parity: none, Stop bits: 1, Flow control: none. Then, restart your Kindle either by removing & reconnecting the battery, holding the sleep switch for 30 seconds, or tapping the reset switch on the PCB. Press Enter when text pops up in HyperTerminal. You only have one second, so be quick. In uBook, type in “run prg_kernel_serial” (make sure to type fast or uBoot will timeout). Then right click on the text, and choose “Send File”. Under protocol, choose Ymodem-G and for the file, select my custom kernel. Wait a few minutes for it to upload and install, then type in “bootm 0xa0060000″ to boot the kernel. The Kindle has two kernels that it alternates on each boot, so if you want to use my recovery kernel, you need to either flash the other kernel also or type in “bootm 0xa0060000″ into uboot on startup. Hold down Enter either on your computer or on the Kindle to enter the recovery menu. The recovery menu times out in 10 seconds, so you need to be quick. First type “I” to recreate all the partitions, then type “3″ to export the MMC. Again, these can be typed from either your keyboard in HyperTerminal, or the Kindle keypad. If you do not have access to HyperTerminal because you are in Linux restoring, you can get back here by holding Enter on the Kindle keypad and pressing 3 on the recovery menu.

Obtaining a backup of Kindle system files

Let’s put your broken Kindle aside. You need a working copy of Kindle’s system files. I cannot provide this for legal reasons, but if you obtain another Kindle 2 (preferably the same model and version as your broken one, but others MAY work [not Kindle 3 though... yet]), jailbreak it and install the usbNetwork hack for SSH access. Make sure that Kindle has at least 500MB of free space on the FAT partition to store the backup image. Once you SSH’d into the working Kindle (there are tons of tutorials around on this), issue the following command:

dd if=/dev/mmcblk0p1 of=/mnt/us/rootfs.img bs=1024

Note that this will only make a copy of the OS files. All personal information, passwords, books, etc are not copied. You can tell your friend that. This may take five to fifteen minutes to run, but when the command returns with the blocks written, you can disable usbNetwork and enable USB storage again. Copy the rootfs.img file over to your recovery computer and prepare to restore.

Restoring your Kindle

Back to your broken Kindle. You need to reformat the root and copy over the backup files. I moved the Kindle over to a Linux computer because it is easier. You can also use OSX or maybe even cygwin, but I haven’t tested. In shell, type in the following commands:

sudo su # Become root, so you don’t need to sudo everything

fdisk -l # Look for your Kindle’s identifier, it should be something like /dev/sdc, it should be a 2GB drive with 4 partitions. I will use /dev/sdX to represent this drive

mkfs.ext3 /dev/sdX2 # Make a ext3 partition for /var/local

dd if=/path/to/rootfs.img of=/dev/sdX1 bs=1MiB # This will take a long time to finish

Note that an alternative method is to gzip rootfs.img and place it into a recovery package created using kindle_update_tool.py, but I’ll leave that as an exercise for the reader.

Appendix

So, what is in the magical Kindle recovery kernel? It’s actually just a regular Kindle kernel recompiled with a modified initramfs with a patched recovery script. Using the regular kernel, you’ll run into two difficulties when trying to recover. First, if you press 3 to export MMC0, you’ll get a password prompt. Good luck brute forcing it. Second, if you build a custom recovery package using kindle_update_tool.py m –k2 –sign –fb, it will not work because of signature checks. What I did was patch the two checks.

First, I extracted the recovery-utils file by gunzipping uImage (with the extra stuff stripped out), and gunzipped initramfs.cpio from that. Then I extracted initramfs.cpio and found recovery-utils under /bin.

Next, the easy part is patching the updater package signature checks. What I did is extract the updater RSA public key file from the Kindle, found under /etc/uks and used OpenSSL to extract the public key from it (n and e). Then I opened recovery-utils with a hex editor, searched for the public key, and replaced it with the jailbreak key (found in kindle_update_tool.py).

Finally, the challenging part was to patch the password check from export MMC0. First I opened recovery-utils with IDA Pro. Then I located the check_pass function. I worked backwards from that and saw it was called from loc_94A8. Here’s a snippet of the check along with my interpretation of what it does:

BL check_pass # Call the check_pass function

CMP R0, #0 # check_pass sets register R0 with the return value, we will check if R0 equals 0×0

BEQ loc_9604 # If the previous instruction is true, then password check has failed

LDR R0, =aDevMmcblk0 ; “/dev/mmcblk0″ # We did not jump out, so CMP R0, #0 is false

BL storage_export # Call this function

It’s always easy to patch the least amount of instructions with the least amount of changes, so this is what I did. (Note that IDA Pro doesn’t allow editing instructions directly, so I have to find the machine code in hex to know what to replace. Luckily, I have tons to instructions to look at and see what their corresponding machine codes are).

NOP # Instead of calling check_pass, I did MOV R0, R0 which is the same as NOP

CMN R0, R0 # Negative compare R0 with itself. Basically, always return false.

… rest is the same

Now, I saved the file and luckily, it was the same size. So I didn’t have to recreate the initramfs.cpio, I just replaced the file inside with my hex editor (note that cpio files do not have checksum checks unlike tar files). I copied this to the kernel source folder and compiled the kernel. Lucky for you, I have already done all of this so you don’t have to.

Quickguide: Bypassing Lenovo S10 BIOS Whitelist

Lenovo loves to assert their dominance to you by whitelisting what WWAN (3G modem) card you can install in your laptop. There has been a way to bypass or remove the whitelist on most models, except the S10. Now I found a great guide here: http://www.sbbala.com/DellWWAN/Whitelist.htm that shows you how the remove the whitelist, but as many found out, it doesn’t always work. The problem is that… well, I don’t know what the problem is, but I’m guessing there’s additional checks. I’ve been trying to find the format of the S10 whitelist, but I’m having no luck, so we’ll do it the easy way. Brute force. Put your WWAN card into every whitelist entry. It’ll have to work then, right?

Now this is a “quickguide” which means I won’t spoon feed you. This is mostly because I don’t have the time to write a full guide, but maybe if I ever find the format of the whitelist or find a way to disable it completely, I’ll write an actual guide.

Basically, follow sbbala’s guide up until “Save and now you can close the hex-editor.” Instead of pulling out after replacing one entry, we’re going to replace a couple of others in MISER00.ROM. Take the PID/VID (little-endian reversed) and replace the follow entries with it:

DB 0B 00 19 (this one was in the guide)

D1 12 01 10 (this one will appear twice, replace both)

D1 12 03 10

C6 05 01 92

D2 19 F1 FF (this one will appear twice, replace both)

Now, I’m sure there are more devices in the whitelist, but for safety reasons, the ones I choose are 1) WWAN cards (I don’t want to accidentally remove the camera from the whitelist), and 2) in the Linux VID/PID list. If this doesn’t work, then try looking and replacing some more values in the whitelist. Although I haven’t completely reversed the whitelist format yet, I THINK it’s something like this. 1 Byte: FA followed by 4 bytes VID (little-endian) followed by 4 bytes PID (little-endian) followed by X bytes of don’t-know-what. The offset is different for every BIOS version, but it’s always in MISER00.ROM and is before DB 0B 00 19 and a bit after a bunch of 00s.

Creating a PSP FreeCheat Memory Patch

FreeCheat is a memory editor and cheat device (like Action Replay) for the PSP. It includes features like a live in-game memory viewer and searcher. One of the feature that intrigued me is the memory patcher. I had no idea what it does, but I assume it does what it says: patches the memory. Problem is: I’ve searched everywhere, but there seems to be no information on how to create a FreeCheat memory patch for the PSP (only .pat files for Monster Hunter). Well, it’s not that hard. After some trial and error, I’ve found out how to create a FreeCheat .pat memory patch. Note that the following should only be attempted by a person with enough technical knowledge to understand it.

To create a memory patch, first you need to find out what you want to patch. I suggest using FreeCheat’s own memory searcher to find the memory location. Another method if using FreeCheat to dump the memory to a file, and open it on your computer with a hex editor. Once you find something you want to replace, look at the address. On FreeCheat, this is the hex number on the bottom left of the memory viewer box. On your hex editor, it should be listed as “address” or “offset”. This should be between 0×0000000 and 0x017FFFFF. Now take this number and add 0×08800000 (hex math please) to it.

You can now create a new file in your hex editor to be the patch. The first four bytes in the file is the memory offset (that you found) in big endian form. The problem is that the offset you found is a little endian number. You need to convert it to a big endian number. Most hex editors allows something like this. I use 0xED on OSX, so on there (make sure it’s set to Edit->Number Mode->Little Endian!), I would type in 00000000, highlight it, and under “32 bit unsigned”, I would paste in the offset I found and it would convert it automatically. Then in the rest of the hex document, fill in whatever you want to replace the memory with. Save this as a .pat file and copy it to your PSP at /FreeCheat/PATCH and on the PSP, open up FreeCheat, go to MEM Manager and Load MEM Patch.

Update: T-Mobile Proxy released: Free unlimited EDGE internet without any plans (for now)

EDIT: This no longer works. If you have the package installed, I would recommend uninstalling it.

I’ve talked about how it works here. In short, I’ve made a proxy server that adds the string “tmobile” to all URL requests on the iPhone because T-Mobile allows internet access to URLs with “tmobile” in it. You can download the deb and install it manually from here. You can also add the repo http://yifan.lu/cydia/ to Cydia. This script works for any unlocked iPhone running T-Mobile including prepaid phones. However, I’m not responsible if you abuse this and get charged. Let’s start the countdown. I predict T-Mobile will have this bug fixed in a month.

Please note that it’s only tested and working on one phone. So it’s pretty beta-ish. If it doesn’t work, please post as much info as you can in the comments, so I can fix it up.

Also, I noticed that it doesn’t work on the internet3.voicestream.com APN. I use wap.voicestream.com and it works there. Another thing that breaks this is any “T-Zones $5.99 hack” (which hasn’t worked for a while now) is installed. The problem is that if you already have a proxy set for ip1 (EDGE/3G) interface, then this won’t work. You can’t modify EDGE/3G proxy information from Preferences.app, so if you manually edited your proxy information in preferences.plist, installed a package that did, or installed a mobile config that did revert the changes to use this.

If all else fails, install my configuration profile by going to http://yifan.lu/cydia/install.mobileconfig from your iPhone and install that configuration profile. It will set the APN and proxy for you.

Page 1 of 212