• 5,598,890
    REGISTERED
  • 30,240
    ONLINE NOW

Posts Tagged: chainfire

sammybrick

By now, you’ve undoubtedly heard about the Samsung HardBrick bug that has reared its ugly head on various Samsung Exynos 4210-based devices including but not limited to the Galaxy Note GT-N7000Epic 4G TouchAT&T Galaxy S II, and the Korean SHW-M250S/K/L. In fact, we recently featured an app made by XDA Elite Recognized Developer Chainfire aimed at determining your particular device’s risk for hard brick.

Samsung is aware of the issue, which was first noted by Elite Recognized Developer Entropy512, and is in the final stages of delivering a solution. Until then, however, it is still advised to not flash any leaked kernels, or kernels in which MMC_CAP_ERASE is present.

As seen on a Google+ post by XDA Elite Recognized Developer codeworkx:

We’ve contacted Samsung about the problem where performing a mmc erase could hardbrick your phone (i9100, i9100g, n7000, m250 – MAG4FA, VYL00M, and KYL00M with firmware revision 0×19 // T989 and I727 with fw rev 0×12) if it’s having a faulty emmc chip.
Read this thread for more informations about it: http://forum.xda-developers.com/showthread.php?t=1644364

They’re working as hard as possible on a clean solution which will be ready soon.

Please be patient and try to not flash any leaked kernels or kernels based on sources where MMC_CAP_ERASE is present.

In fact, earlier today Samsung contacted me to inform the community that progress has been made. In addition simply releasing a fix in the form of updated stock firmware, Samsung is also working with community developers to provide them the information they need to fix the issue in their own releases. This is important because binaries or patches released to end users require extensive (and time-consuming) testing. This way, however, developers can begin to incorporate the fixes as soon as possible.

We’re thinking two steps to provide.

One is to share the information that open source developers can use to fix the problem.
The second one is the patches applicable for both Official Samsung ROM users and Custom ROM users.

Due to our duties to provide more complete binaries to our customers, our patches require the full testing, which takes longer time.
That’s why we want to share the information first.

Good job, Samsung! It is commendable to see not only your team’s efforts to fix the issue, but also work with the community to ensure that the fix is disseminated as quickly as possible!

Those looking to learn more should head to the discussion thread started by XDA Forum Member androidindian.

[Image taken from egzthunder1's fantastic article on the matter.]

The Chainfire Block

Expert news summarizer Jordan returns for today’s episode of This Week in Development. Jordan talks about Microsoft’s on{X} Quick Look and Tutorial. Jordan mentions another XDA Portal news article about a beginner’s app creation tutorialHola Mundo!

Jordan then covers the deluge of XDA Elite Recognized Developer Chainfire’s latest developments, from CF-Root being Released for the International Samsung Galaxy S III I9300, to Possibly the Final Release of TriangleAway for the Samsung Galaxy S III and International Note, to Mobile ODIN Updated for the Samsung Galaxy S III I9300. Jordan talks about the developments for the Xperia Pro, Arc, Arc S, Sola, U and P.  Lastly Jordan reminds you of his Linux tutorial from earlier this week

READ ON »

Advertisment
adbd insecure

We are all undoubtedly aware of adb. In fact, most of us use it quite often in order to execute commands on our mobile devices from the comfort of our computers. It allows you to do this such as push and pull files on the device, retrieve logcats to send to your favorite dev when your kernel causes a bootloop, reboot to recovery or bootloader, and many other useful things. It is also the core of most one-click root methods. Ultimately, it is the adbd (ADB Daemon) that is responsible for allowing you to access the shell and all the other cool functions. For most stock kernels, however, it seems that this only allows you to run adb in secure mode even if you have a rooted device.

So, if you have a stock kernel and want to have all the goods that comes with an insecure adbd (write access to /system goodness and much more), you may want to take a long look at a new release by XDA Elite Recognized Developer Chainfire. He has released an APK that allows your device to run adbd in insecure mode, even if you are rooted and on stock kernel. The app doesn’t enable insecure adbd permanently, and will thus revert to the standard adbd upon reboot. However, there is an option to restart insecure adbd on boot.

There is a good chance that if you are running a custom kernel, you do not need this app. Chainfire mentions that this app must be installed on rooted devices, and that it may not work if your device has a locked bootloader. Please take it for a spin and leave some feedback for the developer.

You can find the free application in the original thread. Alternatively, you can purchase a donate version in Google Play.

Want something published in the Portal? Contact any News Writer.

[Thanks Chainfire for the tip]

unnamed1

Back in November of last year, we took a quick look at Mobile ODIN by XDA Elite Recognized Developer Chainfire. Later in February of this year, the app was updated to version 2.0, which added an impressive number of supported devices. Now, the app has been updated once more to support even more devices, including the device that is seemingly on everybody’s mind—the Samsung Galaxy S III GT-I9300.

For the uninitiated, Mobile ODIN does as its name implies and serves as an on-device ODIN utility. It allows users to fully flash their firmware straight from the device itself—practically removing the need to connect your device to a host computer. Due to safety reasons, however, the EFS and bootloader partitions are not flashed. Just as before, two versions are available: a lite version that is available exclusively on XDA, and a pro version that can be found on the Android Market.

In the words of the developer:

New in v2.10:
- Samsung Galaxy Tab 7.0 Plus GT-P6200
- Samsung Galaxy Tab 7.0 Plus Wi-Fi GT-P6210

New in v2.15:
- Samsung Galaxy S GT-I9003L
- Samsung Galaxy S2 GT-I9100G

New in v2.35:
- Samsung Galaxy S2 SHW-M250K
- Samsung Galaxy S2 SC-02C

New in v2.40:
- Samsung Galaxy S2 GT-I9100M
- Samsung Galaxy S3 GT-I9300

New in v2.45:
- Samsung Galaxy S2 SCH-R760 (US Cellular)

Head over to the original thread to put your ORD to work!

782-galaxy-s3

XDA Elite Recognized Developer Chainfire has done it yet again. After being the first to root the device (sight-unseen, no less), Chainfire has released his nearly ubiquitous CF-Root for the device.

For the uninitiated, CF-Root isn’t a complete ROM, nor does it pretend to be. Rather, it is arguably the simplest entry point to superuser status on your mobile device. Geared towards those wanting to remain as close to stock as possible, flashing CF-Root replaces your original Samsung kernel with a rooted variant. In addition to substituting in a rooted kernel, CF-Root also features CWM Manager and the ported version of ClockworkMod Recovery we covered earlier.

According to Chainfire himself:

CF-Root is the root for “rooting beginners” and those who want to keep as close to stock as possible. CF-Root is meant to be used in combination with stock Samsung firmwares, and be the quickest and easiest way for your first root.

What’s installed
- Root: SuperSU
- Recovery: ClockWorkMod
- Util: CWM Manager

Kernel

Unlike CF-Root for some other devices, this iteration of CF-Root does not include a custom kernel. Your kernel remains the stock kernel, and thus goodies like insecure adbd (ro.secure=0), custom boot scripts, and custom boot animations are not supported.

Root – SuperSU
The root permission management app installed by CF-Root is SuperSU. This will allow your apps to gain root (superuser) access.

Recovery – ClockWorkMod (CWM)
A custom CWM 5.5 build is included in CF-Root, taken from this thread. This provides for the ability to install custom ROMs, and do nandroid (full device) backups and restores.

Util – CWM Manager
My management application for CWM is also installed, see the recovery thread linked above for further details. It allows you to command CWM (install a ROM, make/restore backups, etc) from normally booted Android.

Installation is incredibly simple. Simply use ODIN to flash the CF-Root package, and you’re good to go. Afterwards, you can use the newly updated TriangleAway, at least while it still works.

Continue on to the release thread to get started!

sammybrick

By now, we’re all familiar with the hard brick bug that’s plagued various Samsung when updating to leaked builds of ICS. The bug has shown up on various Samsung Exynos 4210-based devices including the Galaxy Note GT-N7000Epic 4G TouchAT&T Galaxy S II, and the Korean SHW-M250S/K/L.

However, as we quickly found out, not all eMMC revisions were equally afflicted. Instead, the 0×19 revision was highlighted as known bad, whereas the 0×25 is thought to be safe. Revisions between 0×19 and 0×25 are thought to be possibly bad, whereas those newer than 0×25 are probably safe. Adding insult to injury, those keen on hex will be quick to notice that 0×19 converted to decimal is 25!

Naturally, someone was bound to create a simpler way of determining the status of your device, and that someone is XDA Elite Recognized Developer Chainfire. With his new app Got Brickbug, users can easily check their device to see their risk status for the hard brick bug. As explained by Chainfire himself:

Attached is a simple APK that reads out your chip’s type and CID, and lets you know if we know that chip is dangerous or safe.

Just uninstall again after using.

Obviously, this comes “as-is”, we’re not responsible what you do with your device, etc. No rights can be derived from the output of the program!

Internal data used:
MAG4FA, VYL00M, or KYL00M fwrev 0×19 –> known bad
MAG4FA, VYL00M, or KYL00M fwrev >= 0×25 –> probably safe
MAG4FA, VYL00M, or KYL00M fwrev != 0×19 && < 0×25 –> probably bad
Everything else: unknown chip

As this is relevant information for any flashaholic, we recommend you head over to the application thread to test your device.

[Image stolen from egzthunder1's fantastic article on the matter.]

CF_TA

Those familiar with TriangleAway by XDA Elite Recognized Developer Chainfire will take comfort in knowing that the app has been updated to add compatibility with the Samsung Galaxy S III and the International Galaxy Note. For those unfamiliar with the app, it does as its name implies by removing the triangle and resetting the flash counter on your device.

Let’s backtrack for a minute and find out exactly why the app had to be updated, and what made this time a little different than before. At the application’s start, the kernel flash counter was relatively easy to take care of. Simply resetting the value would remove the counter. However, with the release of the Galaxy Note, Samsung made things more difficult by hiding the data. And now on the Samsung Galaxy S III, Samsung has made it even more difficult thanks to a background service that searches for the telltale signs of rooting.

According to Chainfire’s development blog:

With the Galaxy S II, Samsung introduced a custom kernel flash counter and custom kernel warning triangle. This is where Triangle Away came in – it reset the flash counter and removed the warning triangle.
On the Galaxy Note, Samsung tried hiding the data once more, so Triangle Away would not work.
On the Galaxy S III (among other new devices), Samsung has gone a step further, and has introduced a background service that runs on your device and checks for things such as a modified /system, apps running with root access, etc.

For the moment, this service does not do anything malicious, but who knows what the future will bring ? Tracking of IMEI’s that have ever ran root, disabling of services, etc ?

Scary, isn’t it? The last line should jump out at you, as it’s not too much of a stretch to think that future revisions of the service could be used as such. And by looking at the update log, you can clearly see the battle between Chainfire and Samsung:

Update 16.02.2012: Users have confirmed TriangleAway works on the I9220 SGNote ICS leak !
Update 13.05.2012: TriangleAway does *not* work on the latest official SGNote ICS firmwares. There will be a fixed version soon, but it has to wait for my Note to return from repairs, else I cannot test it 
Update 04.06.2012: v1.50 should work with the I9220 and N7000 SGNote’s again

Right about now, you may be wondering why exactly Samsung or any other OEM would feel the need to keep tabs on your ORD. One can assume that it has to do with warranty, but is this really a valid reason on Samsung’s part? After all, if the hardware functioned properly, why should an improper firmware flash even have the capacity to damage the hardware?

Once again, according to Chainfire himself:

Custom ROMs, root, bricks, and warranty

I am not sure what the reason is Samsung wants to track all this. My reason for wanting to “break” their tracking is one thing: warranty.

Being able to run the software I want on devices I own without losing hardware warranty should be a right by law. As for as I can see, there’s only two ways you can really break your device with root access:

(1) overclocking to the point where hardware is damaged
(2) flashing nonsense to your bootloader partitions

I’m not sure how to handle (1). I personally never overclock – and I don’t think it’s strange to deny overclockers warranty. Surely this must be preventable in the hardware. Case number (2) however is wholly Samsung’s fault. Adam Outler has shown time and again that these devices are perfectly able to be made unbrickable - so any bootloader brick is IMHO Samsung’s fault. If Adam Outler can prevent the situation with a soldering iron, the original design is broken.

Regardless, hardware should be under warranty – if I have my device rooted or not. Leaked service center documents show that devices should be checked for root, and if present, deny warranty. (This is not just Samsung, all the major OEMs do this.)

That is simply unacceptable. Any OEM following that policy is a bad OEM – in some countries this may even be an unlawful practise (though good luck winning in court). HTC has once refused to replace a defective digitizer on my HTC Diamond (a common hardware issue with this device) due to HSPL being present. They claimed HSPL had irreversibly damaged the mainboard, and the entire innards of the device would have to be replaced. Riiiiight.

Root by itself is not a crime, nor a pointer that a device is broken in any way that should not fall under warranty. But in the eyes of the OEMs it seems we are criminals.

If the purpose of the tracking is related to corporate security and such, I can see why Samsung would want to lock down further. I can certainly understand that, though I don’t necessarily agree.

If this reminds you of the mid-nineties, you are forgiven. As Chainfire writes, there is nothing inherently malicious or criminal in being able to use our own devices as we see fit. Yet, various OEMs employ tactics aimed at preventing us from truly customizing our devices to our hearts’ content for fear of a voided warranty.

If (using Chainfire’s personal example) broken digitizer hardware has absolutely nothing to do with flashed firmware, why is that justification for denying warranty service. For those who tinker with their cars, this is akin to voiding a Powertrain Warranty because you added an aftermarket radio. There is simply no justification—morally anyhow. Luckily for those in the US, the Magnusun-Moss Warranty Act offers a sliver of protection—but good luck trying to take that to court. And in other countries, you may be entirely out of luck.

This then leads to the question of what would be best, both practically and ethically. Chainfire has assessed the situation stating:

And thus we come full circle – if Samsung goes another step further in protecting their custom flash data, will I even attempt to bypass it ? Should I ? A big part of me thinks not.

Those simply looking to absolve their triangle and flash counter for what is possibly the last time can purchase a donation version of the app on Google Play or head to the original release thread for the free version. Those simply looking to learn more on the issue should head over to Chainfire’s development blog post.

 

ClockworkMod-Recovery-3_thumb

Samsung Galaxy S III this, SGS3 that—it seems like everywhere you look, the mobile tech industry is aflutter with news on Samsung’s latest flagship. Fittingly, there has also been a plethora of development surrounding the device—everything from achieving root access and the release of GPL-compliant kernel source to its launcher and proprietary apps ported to other devices.

We now have a custom recovery thanks to XDA Elite Recognized Developer Chainfire, who coincidentally was the first to root the device sight-unseen, well before official release. The recovery itself is an unofficial port of ClockworkMod 5.5. 0.4. Due to the way CWM works, there were a few quirks along the way. However, Chainfire seems to have squashed them, and tells us:

As is the case with every SGS release (it happened with the SGS1 and the SGS2, and now again with the SGS3), CWM source isn’t built to correctly deal with our setup (internal storage vs sdcard). I had to make a number of changes to the source to get it working correctly. From my tests, it all seems to work, but it’s quite possible I missed something (report issues).

(I have tested backup/restore to both internal and external storage, wipes, installing zips from both internal and external, etc, all works as I expect it to)

Aside from the base fixes, there is currently nothing fancy about this build of CWM. I’m not sure if the SGS3 suffers from the brick bug (that SGS2 and Note have), but I patched out the relevant code to be sure (I think). Backups are rather big, system alone is about a GB.

Those lucky enough to own the SGS3 already, or those eagerly awaiting their own, should head over to the recovery thread.

[Big thanks to Member Advocate Admin Egzthunder1 for the tip.]

Untitled-2

Yesterday was a sad day we all knew would eventually come—the Windows Marketplace for Windows Mobile applications finally ceased to exist, as Microsoft officially killed Windows Mobile and mostly everything related to it sometime last year.  The market brought the capability to do what Apple’s Appstore was doing at the time, which was to try and centralize all the available free and paid applications so that people could easily find their favorite apps in one, single place. The introduction of the marketplace didn’t come without its share of issues and scandals due to various flaws in functionality. For instance, Windows Marketplace was restricted geographically. More specifically, you couldn’t use it in certain parts of the world because your device would simply not be allowed access to the servers. Please note that this practice still takes place today with services such as the Amazon Marketplace, Hulu Plus, and several other popular services.

Of all the gripes that people had with Microsoft about protection, the copy protection patch that Microsoft released sometime in 2009 was by far the most annoying. Essentially, it forced developers to submit the applications in such a way that they could not license it under their own models. Instead they had to be licensed by Microsoft under a single model. The patch forbade people from protecting their apps, and because of that, they could be bypassed and even have the code stolen and copied. XDA Elite Recognized Developer Chainfire cracked this new “protection” measure from Microsoft within two hours of it being released. The license check was easily bypassed, and he created a hack to go around it, disabling the license check code added by MS to all the apps in the MP. Due to his own morals, Chainfire decided not to release this hack for a very simple reason… it could be used for piracy.

Today, since MP is already dead, he has decided to go in full detail regarding how me managed to crack Microsoft’s protection model in less time than it takes to prepare a good meal. Oh, and he did it in Pascal (yes, yes… roll in agony). He also went ahead and released the source code via github, which can be found in the link below. If you are interested in some history and overall hacking insight, please be sure to visit his blog (linked below).

Now that Marketplace for 6.x has been closed, I thought it time to release some WM hacking/patching details and some source for this claim of cracking the Marketplace.

You can find more information in the original thread as well as Chainfire‘s blog. And if you still want more Chainfire after all that, be sure to check out his interview. Thank you Chainfire for all your hard work.

Want something published in the Portal? Contact any News Writer.

[Thanks Chainfire for the tip!]

attachment

Not too long ago, we went hands-on with the Samsung Galaxy S III. In fact, XDA Elite Recognized Developer Chainfire, who was later kind enough to go on camera for a fun interview and unboxing, even made a brief cameo in the video as we tested USB Host functionality on the SGS3 using his popular DSLR Controller app. Needless to say, much of the Android community is eagerly anticipating the launch of Samsung’s new flagship.

However, many people won’t bother with devices that aren’t rooted. Luckily this has been quick to achieve on Samsung devices in the past, and the Galaxy S III is no different. Before the official release, Chainfire has managed to root the SGS3. While Chainfire is currently unable to release the insecure boot image because it may be traceable, this most likely won’t be the case for long. In his words:

Unfortunately, I am not able to share the “insecure” kernel with you at the moment, because of fears it is traceable to the leaker (this is said to be the last traceable firmware revision).

This root is, as expected, trivial. It was a simple matter of repacking the stock kernel, with a modified adbd binary that thinks ro.secure=0 (even if ro.secure=1). This gives access to all adb root commands (see screenshots). Then SuperSU was installed manually.

Kernel - The modification was trivial, because this time around, Samsung is using the standard boot.img format, instead of the zImage format used for SGS1, SGS2, SGNote, etc, that is much harder to repackage.

Recovery - The recovery partition is also being used this time around. And thus we can flash recoveries separately from the kernel.

Bootloaders - There was no warning triangle at boot-up after flashing the modified kernel, but download mode did show a custom kernel flash counter which increased. Whether or not flashing a custom recovery also triggers this counter is as of yet unknown.

Final note - This was all tested on a current (release candidate) SGS3 firmware. There may be a newer firmware on true retail/production devices. Though some things may change, it is unlikely to changemuch. Let’s hope nothing 

Also, Triangle Away did not work. They have hidden the boot partitions again as on the latest SGNote firmwares.

(No, I don’t have an SGS3 yet, everything was done remotely)

Now if you take a closer look at that last line, you’ll see what is perhaps the most impressive aspect of Chainfire’s achievement. Not only is he the first to root the device, but he did so working remotely, sight-unseen.

What are you waiting for? If you’re lucky enough to have your hands on a pre-release SGS3, head over to the original thread to learn more. This is exciting news even if you don’t yet own the device, but wish to purchase one in the near future!

chainfire_will

You may remember that we were on-site for the Samsung Galaxy S III unveiling at Unpacked 2012 in London last week. We then went hands-on with the Samsung Galaxy S III and showed you its cool gestures, blazing fast performance, and USB host capabilities. Not content with simply calling it a night, what then are two self-proclaimed Android nerds to do at 3 AM after the event? Interviews, of course!

Join us in today’s episode of XDA Developer TV, where I had the honor and pleasure of interviewing XDA Elite Recognized Developer Chainfire in an extremely late night interview session. We start off by “unboxing” the “Samsung Galaxy S III.” We then talk about the Samsung Galaxy S III, including what we like and what we don’t like. Then, Chainfire talks about his personal life, hobbies, development history, favorite projects, and those that have made him want to demolish his computer. For those living under a rock, Chainfire is responsible for WMWiFiRouter, CF-Root, CF-Bench, Chaifire 3D, DSLR Controller, and a plethora of other development work. You can find a selection of his development work on the XDA Portal and of course in Chainfire’s signature on the XDA Forums.

In case you haven’t already started watching, this is an interview you do not want to miss. Grab some popcorn, hit play, and prepare to be amazed.

READ ON »

unpacked

You may have already read through our live-blog of the Samsung Unpacked 2012 launch event for the Samsung Galaxy S III. However, a picture is worth a thousand words, and therefore a little hands-on video must surely be worth even more.

In this episode of XDA Developer TV, we get a little hands-on time with Samsung’s latest flagship, and our own Portal Administrator Will Verduzco (that’s me!) puts the SGS3 to the test. We begin by taking a look at browser performance and voice control. Then, we test for USB host functionality (hint: it works) using Elite Recognized Developer Chainfire‘s DSLR Controller App. Finally, we examine the size compared to the Samsung Galaxy Nexus, and cover some notable additional features and gestures.

If you’re currently salivating at the thought of Samsung’s latest and greatest, make sure to watch the video below!

READ ON »

odin-example

If you’re a Galaxy Nexus owner who hasn’t been living under a rock, you are undoubtedly aware that Android 4.0.4 Ice Cream Sandwich was recently rolled out. Unfortunately, it would seem that some people have had trouble with the OTA update, including XDA Elite Recognised Developer Chainfire, who promptly came up with a solution to the problem.

Chainfire has repackaged the full stock images for the international GSM Galaxy Nexus (yakju/maguro) for use with Odin, the flashing tool for Samsung devices. This should allow anyone with similar issues to easily install the update to stock 4.0.4. While some Galaxy Nexus owners may be unfamiliar with Odin, it’s a completely viable alternative to performing the same actions via fastboot, and offers a high degree of noob friendliness. Another bonus is that these images will also work with Chainfires Mobile Odin, allowing you to flash without a PC. If you are unfamiliar with Odin, don’t despair. There are crystal clear instructions on how to flash the images provided.

There are two versions available. The first is a “No wipe, no recovery, no bootloader” version that leasves your recovery, bootloaders, and user data intact. This version should only be used if your device is already OEM unlocked—otherwise your data will be wiped. There is also a full stock image that will leave you with a complete stock installation of 4.0.4.

Whether you’ve also been experiencing problems with the OTA or just want to grab the images then check out the ROM thread.

Advertisement

XDA TV: Most Recent Video

Buy/Sell on Swappa