Flashing frp.bin to bypass Factory Reset Protection, is it really wise?

Factory Reset Protection (FRP) has been one issue plaguing more Mediatek devices since Lollipop. We’ve dedicated a thread to bypassing FRP on Mediatek devices and it features several methods which are helpful in unique scenarios. One method however seems to be on the rise, flashing an frp.bin. While this method seems convenient, its not sustainable. In order to understand why I think so, lets take a moment to understand what FRP really is.

What is Factory Reset Protection (FRP)?

Some Android versions ago, if you forgot the pattern or PIN lock used to protect your phone, you could easily remove it by doing a factory reset in recovery mode. Although there were other methods that didn’t require losing data, a factory reset was easiest to pull off since it didn’t require root.

Fast-forward to Lollipop (and above), the story began to change as Google wanted to make your device more secure. We then began seeing Privacy Protection Password (PPP) and Factory Reset Protection (FRP).

Once you are signed into a Google Account (Settings > Accounts > Google) on an FRP enabled Mediatek device and do a factory reset (whether from Settings > Backup & reset or Recovery mode), you’ll be asked to provide the credentials of the Google account previously associated with the device.

Verify your account Google This device was reset‘ To continue, Sign in with a Google Account that was previously synced on this device. Enter your emai

This is Factory Reset Protection and is managed by the frp partition. If you know the credentials and have an internet connection then simply inputting will allow you to proceed, else you would have to bypass.

Bypassing FRP the wrong way

During a live chat session with a visitor (via Hovatek IMS), he mentioned that he’d bricked his phone after flashing an ‘FRP file’ to his phone. I was curious where he’d obtained this FRP file because we not only do not include frp.bin in our Individual files project but are also unlikely to recommend flashing frp.bin to just anybody.

It turned out it was from some website which just provided an FRP file and called it the ultimate FRP bypass file. Several other similar complaints followed suit, all having flashed some FRP file they’d found online. They each had to download the full firmware from us in order to fix their devices.

The general principle for bypassing FRP is to target the frp partition. While flashing an frp.bin to replace the current frp is a valid technique, its only advisable you do so with an frp file obtained from the firmware / stock rom / flash file for your phone model (and exact Build Number in some cases). These ones however didn’t understand phone models and variants.

Why flashing frp.bin isn’t always a good alternative

Flashing the frp.bin to bypass FRP is a brilliant technique but only when you’re using an frp.bin for your phone mode. The next thing you’re probably thinking is how can I get the frp.bin for my phone model. The bad news there is that you’ll likely need to download a firmware of over 1.5GB just to get a file of 1MB (if its even included).

When we began deliberating on which files to include in our Component / Individual Files Project, system.img, cache.img, userdata.img and frp.bin were dropped for clear reasons:

  • System.img: This makes up most of the size of a firmware so it makes no sense to upload a system.img of over 2GB when the entire firmware is just about 2.5 GB
  • Userdata.img & cache.img: These are optional files and your phone will work fine whether or not you flash them. You just need to do a factory reset after flashing
  • Frp.bin: This is a specific file i.e you should not be using one model’s FRP file on another. Even flashing frp.bin between variants could brick your phone.

If we had included frp.bin then it would have been with the aim of using it to bypass FRP. We’d anticipated people would misuse the file and decided against this. If you’re thinking we just list the frp.bin files and let the person be responsible for his / her actions then that hasn’t exactly been working with our collection of Mediatek scatter files . We still have people complaining bitterly and calling the collection fake when the scatter file downloaded (for their chipset) doesn’t work for their phone despite the explanation on page 1.

Making the FRP bypass using the frp.bin file possible and safe would require collecting frp.bin for each phone model (and variant). This is one project that’s not practical or sustainable at the moment, maybe it will be in the future.

Bypassing FRP the correct way

A more sustainable approach is to simply format or wipe the FRP partition. This approach has even worked in bypassing FRP on Spreadtrum devices where the target partition is persist. Even boxes / dongles simply wipe the frp partition, this is why we recommend the approach instead.

Have you encountered FRP on your Mediatek Android phone? Tell us how you were able to bypass it



  1. Of course, the best way to remove frp is by deleting it and not flashing another frp.bin on it. But i have noticed that when you wipe the frp partition on some devices the frp is gone for good. Even when you put another account and factory reset the device the frp does not appear ever again. I don’t know why

    • You are right, wiping the frp partition is the best way. I’ve never encountered such a situation where FRP disappears after a wipe and will surely be on the lookout for such scenarios.

  2. Hi,
    Would just like to say I found your site and the explanations to be probably the best on the web, step by step and informative, I had used SN, and SP, for writing IMEI and upgrades fron AN6 to 7, but failed to write custom roms.
    Tried twrp, through ADB, that loaded ok, but writing custom roms provered problomatic, from the sd card loading any custom would fail, twrp appeared to write all ok, but on reboot failed to find anything other than twrp.
    I have a fairly new Oukitel U20 Plus, dec 2017, it had android 6, flashed to 7, no problem, but still cant flash any custom roms, I wonder if this is a common problem with Oukitel, cant get rid of the original boot loader, returns to Oukitel boot screen, even tried sideload through adb/twrp, fastboot oem unlock, fastboot flash boot loader, I`m sure you know all the coms, soft bricked it, recovered to android 7 through SP, very frustrating not to be able to flash a custom rom, guess I`m stuck with stock roms,
    Thanks for a great site, very instructive, do you have any articles on how to write barcode, through SN,or SP, would be interested to see how you approach that.

    • The problem you’re having with custom roms could be that the custom rom isn’t fully compatible or well ported for your device, and not that custom boot.img brick your phone. To put my theory to the test, flash back your Android 7 firmware then patch boot.img using magisk at https://forum.hovatek.com/thread-21427.html . You can then flash the boot.img alone using SP flash tool. If your phone boots up fine and has root then that proves my theory right.
      If on the other hand,flashing the patched boot.img results in a bootloop then your phone must have dm-verity. This can be bypassed though.

      Concerning writing bar code, you can do so using SN writer ( https://forum.hovatek.com/thread-12306.html ) by ticking barcode. You can also write bardcode using Maui Meta ( https://forum.hovatek.com/thread-12328.html ) ; that’s discussed at the end of the post.

Leave a Reply