#emmc vs sd card | Explore Tumblr Posts and Blogs

tech-battery · 4 years

Text

Battle of the $350 laptops: Acer Swift 1 vs. Gateway Ryzen 3 3200U

We've been on the lookout for good but seriously cheap laptops for a while now. Acer's $650 Swift 3 is an excellent choice for budget laptops in the under-$700 range, but we've been really itching to find one in the almost nonexistent sub-$400 category. To that end, today we're looking at two of Walmart's finest—a $378 Acer Swift 1 and a $350 Gateway GWTN141-2. Both of these are serviceable if cheap laptops, but the Gateway, despite being the less expensive model, will be the clear winner for most people. It's more powerful, more repairable, more upgrade-able, and in our testing, a bit more reliable as well.

Acer Swift 1 SF114-32

Thankfully, the off-putting dingy yellow POST logo isn't in your face for long—the Swift 1 cold boots to the desktop in about 11 seconds.

We found the keyboard pretty unremarkable. It makes maximal use of the Swift 1's chassis, so it doesn't feel too cramped—but we already know some of you will hate the compressed arrow key layout.

DC barrel jack, full-size HDMI out, USB-C, 2x USB 3.0 type-A.

SD card slot, 3.5mm audio combo jack, USB 2.0 type-A, power and HDD LEDs, Kensington lock slot.

If you want to get into the Swift 1, you'll need a set of Torx bits. But there's no reason to bother, unless you're replacing the battery—or, we guess, the Wi-Fi—since everything else is soldered to the board.

Once you (very carefully, due to the thin aluminum side panels) lift off the back panel, there's not much to look at—no active cooling, and no sockets either, except for the Wi-Fi and one unpopulated, SATA-only M.2.

We didn't actually intend to test or review the Swift 1—we ordered a Walmart Motile 14, with a Ryzen 5 processor for only $350. But Walmart has an unfortunate tendency to just throw in any similar product when it runs low on stock, and the Swift 1 is what got sent in its place—with no notification, either by email or in our account at Walmart.com, and no paperwork in the box either.

There's only a 30-day return/exchange window on laptops at Walmart, but Things Came Up, and we didn't open the box until after that window had shut. Discovering that our Ryzen 5 laptop had magically turned into a Pentium Silver (roughly Celeron-class) laptop and there wasn't anything we could do about, it did not spark joy... but it is still an under-$400 laptop, and we're here to test and review cheap laptops, right?

Physically, the Swift 1 strongly resembles a lower-end Chromebook. It's not particularly lightweight, but it's quite slender, and its silver-skinned good looks are unassuming. On the plus side, it has a metallic chassis, not plastic; on the minus side, that chassis is extremely thin and very easily bent up. When we disassembled the Swift 1, despite being extremely careful and using a soft plastic spudger, we still bent the right side a little bit while getting the back panel off.

The best feature of the Swift 1 is its fast boot times—you can expect a cold boot to get to the Windows 10 desktop in around 11 seconds, including POST. Unfortunately, the high performance ends there—the Swift 1's Pentium Silver CPU, 4GiB RAM, and 64GB eMMC storage combine for a pretty lackluster experience.

Everything on the Swift 1—with the exception of the battery, the Wi-Fi chipset, and one unpopulated, SATA-only M.2 slot—is soldered on, unrepairable, and un-upgradeable. What you buy is what you get, and it works until it breaks.

Gateway GWTN141-2

We've got to give EVOO credit for one thing—they nailed the Gateway branding with that wallpaper.

We have a feeling some of you will be excited about that uncompressed arrow key layout.

The fingerprint reader on the Gateway is built into the touchpad—this was a new one on us. Note the dark square in the upper left.

Kensington lock slot, DC barrel jack, USB 3.0 Type-A, full-size HDMI out, USB Type-C.

SD card slot, 3.5mm audio combo jack, USB 3.0 Type-A.

Behold, a mystery panel! It looks pointless at first glance, but there's actually an M.2 slot under there at the top. I think I'd rather pull the whole back off than try to mess around in that tiny panel though.

The Gateway is very easy to disassemble; just Philips screws and pop things loose. The plastic chassis felt sturdy enough to survive quite a few disassemblings.

Looking a little closer, we see an active cooling system, an empty DDR4 DIMM slot, an occupied M.2 NVMe slot, an empty M.2 SATA slot, and an unfortunately soldered Realtek Wi-Fi chipset.

On the left, we see the currently empty M.2 slot, which is silkscreened as SATA only. By contrast, the occupied M.2 (with the C: drive in it) is silkscreened PCIE/SATA.

We went into testing the GWTN141-2 with a mixture of excitement and trepidation—on paper, a Ryzen 3200U system for $350 is a great deal. But in practice, we'd discovered that the new Gateway line is—like the horrid $140 EVOO EV-C-116-5—manufactured by Shenzhen Bmorn Technology and imported by EVOO. We're happy to say that the GWTN141-2 is not a repeat of the EV-C-116-5's story. The Gateway's Ryzen 3 3200U CPU was not limited by substandard thermals or factory underclocking, and it performs as you'd expect from looking at public leaderboards. The Gateway offers an even faster cold boot than the Swift—we timed it at eight seconds from power button to Windows desktop.

Continuing the Gateway's tale of "Hey! Not bad," the 128GB SSD might be an odd Chinese brand you've never heard of, but it's a real M.2 NVMe SSD which can be replaced or upgraded. Although the 4GiB RAM the system comes with is soldered to the board, there's an empty DIMM slot available. There's even an empty M.2 SATA-only slot, with an easy-access panel for that slot on the back.

The only real flies in the GWTN141-2's ointment are its cheap plastic chassis and its equally cheap Realtek 8821CE Wi-Fi.

The plastic used for the chassis is noticeably softer than you might expect for a laptop; it feels more like a kid's toy than a real computer, and it even felt slightly tacky to the touch on first unboxing. (Your mileage may vary, here—it bothered me, but the Spousal Opinion was "Whatever, it's fine.") On the plus side, the plastic chassis felt sturdy enough to survive plenty of disassembly and reassembly, unlike the Swift 1's razor-thin aluminum side panels.

The Realtek Wi-Fi is serviceable if slow under Windows, but it will cause severe headaches for anyone wanting to install Linux—and unlike most of the GWTN141-2's gear, it's soldered to the board and not replaceable.

Performance

Passmark CPU testing demonstrates just how much air there is between these four laptop models—the $650 Swift 3, the $350 Gateway and Swift 1, and the $140 EVOO.

We're not really used to seeing big differences between single-threaded Passmark scores. The near-doubling of Swift 1's score by the Gateway is worth sitting up and noticing.

Cinebench R20 tells roughly the same story Passmark did—namely, the Gateway's Ryzen 3 3200U is far more CPU than the Swift 1's Pentium Silver N5000.

Once again, we see big air between these laptop models, even on single-threaded tests. Notice the EVOO has dropped out of the race entirely at this point.

Geekbench 5, as usual, flattens the differences between CPUs noticeably more than either Passmark or Cinebench. We believe Passmark and Cinebench serve as far references for the difference between Gateway's Ryzen 3200U and Swift 1's Pentium Silver.

Geekbench 5 continues the trend of showing big air on single-threaded benchmarks between these laptops.

Gateway's "Netac" 128GB SSD isn't very impressive by NVMe standards, but it crushes Acer's soldered-on 64GB eMMC without breaking a sweat.

The stars of our show today are, of course, Acer's $378 Swift 1 SF114-32 and Gateway's $350 GWTN141-2. But for reference, we're throwing in a couple of spoilers—Acer's $650 Swift 3 SF314-42, and EVOO's unspeakable $140 EV-C-116-5 doorstop.

We think it's important to relate the Swift 1 and the Gateway not only to one another, but also to a "real laptop." We also think it's instructive to compare the Swift 1, in particular, to the EVOO—because the gap between the two underscores the fact that the Swift 1, though no match in performance for the Gateway, is—for the most part—a usable laptop.

With that said, we find it difficult to recommend the Swift 1 over the Gateway. Although the Gateway's older Ryzen 3 CPU is no match for this year's Renoirs, it's still no slouch—and it absolutely dominates the Swift 1's Pentium Silver N5000. Gaming workloads will bring the 3200U to its knees, but there was never a time we felt like rolling our eyes and saying "ugh" at the Gateway during normal desktop or Web-based use.

The Swift 1's Pentium Silver N5000 is an entirely different beast, designed for maximum electrical and thermal efficiency with everything else left to go hang. It's roughly half the speed of the 3200U in most tests—but it gets by with entirely passive cooling, and the battery life is frankly pretty crazy. In most use, the Swift 1 struck us as reasonably responsive—but unfortunately, it's not hard to find Web-based workloads in which it struggles.

Specifically, the Swift 1 choked badly on Facebook's new layout. Attempting to type a short paragraph about electrical connections resulted in text buffering—leaving us to watch as it "typed" itself out, character by laborious character, for another couple of minutes. To be fair, this is more about Facebook sucking than about the Swift 1—but also to be fair, a lot of people will expect to use Facebook on their new laptop.

We have to stress that the Gateway is absolutely no gaming laptop—it turns in a Time Spy score only a third of the Swift 3's, and the Swift 3 itself is only a budget laptop. But the Swift 1 can't even run the test.

The less-demanding Night Raid tells roughly the same story—the Gateway gets a third the Swift 3's score, while the Swift 1 fails to complete the test.

The differences between the Swift 1 and the Gateway are even more apparent in gaming tests, where the Gateway's scores aren't great, but the Swift 1's score is "I can't do this."

3DMark warned us "this system does not have enough VRAM and may not complete the test" on both systems, but the Gateway completed the tests fine (2 fps on Time Spy is "fine," right?), while the Swift 1 crashed out entirely within seconds of beginning either test.

If you want to run a game from 2010, you might do OK on the Gateway. On the Swift 1, we sincerely hope the only kind of gaming you want to do is interactive fiction.

Battery Life

Both laptops have good battery life, not-so-good stability. Using Event Viewer to find crash times got to be a regular thing.

Neither laptop successfully completed the PCMark 10 Modern Applications battery life test. What you're seeing from them isn't "time before shutdown" it's "time before crash."

Since both laptops crashed under PCMark 10's Modern Apps testing, we tried our go-to YouTube clip at 1080p in fullscreen. The Gateway delivered ten hours of playback—longer than the actual video clip!—but the Acer still crashed.

Trying to test our two ultrabudget laptops for battery life was a frustrating exercise, to say the least. The short version is they both offer excellent battery life—which you may not get all the way through before needing to reboot due to a crash.

Neither laptop lasted all the way through PCMark 10's Modern Office battery-life test. Both crashed well before the battery itself was exhausted. The Swift 1 did at least survive for slightly longer than the Swift 3's (successful) test run; but the Gateway couldn't make it much past four hours before suffering an application crash.

With no good data from the Modern Applications battery test, we tried falling back on something simpler—loading up the BBC's 10 Hours of Relaxing Oceanscapes on YouTube and playing it in full-screen at 1080p until the battery died.

The Acer Swift 1 failed this test as well. After crashing at 4 hours 20 minutes, it tumbled into a strange, half-brightness version of its POST screen. The Gateway, on the other hand, managed to play the clip for a solid six hours and forty-one minutes before shutting down at 5 percent battery.

Scoring this one decisively is a challenge. A sticker next to the touchpad on the Swift 1 boldly claims "up to 17 hours battery life"—we certainly weren't able to verify that figure, but to be fair, we can't really falsify it either. We found the Gateway's more-than-6.5-hour YouTube playtime stellar—but given that it, too, failed to complete PCMark 10 Modern Apps testing, we can't get too excited about it.

Neither laptop is likely to disappoint on the very specific grounds of battery life—but you should definitely save your work before going to bed.

Can it Linux?

The Swift 1 "just works" on Ubuntu 20.04—the only unclaimed device is the fingerprint reader.

The Gateway's Realtek Wi-Fi is a no-go on Ubuntu 20.04. It's possible to download and locally compile a driver from various sources on Github—but it'll break and need fiddling after kernel upgrades.

The Acer Swift 1 worked fine out of the box with Ubuntu 20.04. It lacked for nothing but a driver for the fingerprint reader, which most Linux users don't expect anyway.

The Gateway, unfortunately, should be considered a no-go for most Linux users—its Realtek 8821CE Wi-Fi does not have in-kernel support, and getting it working is a painful slog of finding a driver on someone's Github, downloading and building it locally, and waiting for it to break on the next kernel upgrade.

Extremely ambitious Linux users might be able to turn the Gateway into a good Linux system by putting a $20 Intel AX200 Wi-Fi 6 card—connected with an M key-to-A+E key converter—in the Gateway's empty M.2 slot. We can't guarantee that'll work, but if you try it, let us know how that goes!

Due to limited time, we did not battery test either system under Ubuntu.

Refurbished, or new?

Enlarge / The Ryzen 3 3200U in the Gateway is a better all-around CPU than anything we could find used for a similar price.

One of the more common refrains in the Ars comments when we test inexpensive laptops is "I can do better buying used!" In this under-$400 class, we don't believe that's actually the case. We went looking on Amazon and eBay for refurbished laptops under $400 and found five of the most common CPU models for those laptops. Then we used public Passmark leaderboards to compare those CPUs to what's in the Gateway and the Acer we reviewed today.

The first thing we'd like to point out is that, unless you've got a cousin looking to unload something fast, you aren't going to get a great refurbished laptop for $400 or less. We didn't find anything newer than Intel fifth-generation Core CPUs in this price bracket. That means a 6-year-old system. Worse, quite a lot of the systems in this bracket had second-generation i5 CPUs, marking them as a whopping 9 years old.

The best-performing CPU in our scavenged finds is an Intel Core i5-4300M. This 7-year-old M-series manages to outperform our sole fifth-generation part due to its whopping 37W TDP—it's configured for power, not efficiency, which in turn means poor battery life, especially if your refurb is still limping along on the OEM battery.

The Core i5-4300M handily outperforms the Swift 1's Pentium Silver N5000, but the Gateway's Ryzen 3 3200U beats it by 25 percent on multithreaded tests and about 15 percent on the single-threaded tests. Add in a new NVMe SSD versus whatever SATA garbage the refurbisher threw in for cheap, DDR4 RAM instead of DDR3, Vega 3 graphics versus HD Graphics 4600, and a one-year warranty versus typically 30 days, and the Gateway is obviously a far better deal.

Do you think we got this wrong? Hit us up in the comments—but please, keep it realistic. A single oddball sale you found in your local Facebook marketplace doesn't count; we're looking for readily available, refurbished laptops from dealers who can be found on Amazon, Newegg, or eBay.

Conclusions

We can't recommend Acer's Swift 1 SF114-32 for most users. Although it's handsome on the outside and boots quickly, it just doesn't offer enough muscle for some common workloads—such as Facebook's new and rather blecherous Web interface, which drowns the N5000 in more Javascript than it's ready to handle.

The Gateway GWTN141-2, on the other hand, is absolutely a credible laptop. It's certainly not a great laptop—we don't love the fact that it, like the Acer Swift, crashed out of the PCMark 10 battery test—but it's got enough muscle to make it through light workloads without complaint. It's even willing to take a stab at some older games if you want it to.

We tested the webcam on both laptops in three conditions: dim office lighting, harsh forelight with a studio flood, and harsh backlight with a studio flood. It would be difficult to tell one laptop from the other on the basis of webcam images; in both cases, all three (difficult) lighting conditions produced grainy, but acceptable images with clear facial features. You wouldn't mistake these for a mid-grade or better Logitech standalone, but you also wouldn't mistake them for the no-name garbage we had to settle for earlier this year to get kids online for school.

The speakers were similarly "it works, meh" on both systems—usable, but tinny. We definitely would not advise anyone to set any store in "tuned for THX" (as the Gateway proudly declares itself) anymore.

You should know what you're giving up by dropping down to this under-$400, ultrabudget laptop class—if you've got the extra $300 to spend, you get an enormous amount of additional performance, stability, and general quality out of an upgrade to Acer's Ryzen 7 4700U-powered Swift 3. But if you just don't have the extra money—or just don't want to spend it—the Gateway GWTN141-2 gets most jobs done just fine.

0 notes

appliancesreviews · 5 years

Text

Smartphone Storage Review

For several years, smartphones have been steadily leading in popularity in the consumer electronics segment. Enormous competition encourages companies to constantly expand the functionality of their models. For example, companies already offer Projector Mobile Phones with a projector function, including the very popular Blackview MAX 1 Projector Mobile Phone.

But to a greater extent, the choice of optimal phonedepends on its price, brand and specs, including OS, smartphone performance, camera, screen, etc. Of course, smartphone storage is one of the main characteristics, affecting its performance.

Smartphone Storage

Any technical discourse is often accompanied by a free interpretation of concepts and terms that cause confusion. Smartphone Storage is no exception. But a simplified classification will help to eliminate this factor. Functionally, it includes ROM, RAM, internal memory, and external memory cards. By analogy with a PC, ROM corresponds to the C drive with OS on the HDD or SSD, and internal memory corresponds to the user partitions. Of course, non-volatile ROM (Read Only Memory) stores data even in the event of a power failure. ROM has high speed, provides the same access time to all cells and is used for OS. The ROM in smartphones uses dedicated partitions in the internal memory (eMMC or UFS) in read-only mode (via software). Respectively, this system partition is protected from accidentally deleted or edited. The volatile RAM (Random Access Memory) does not save information after shutdown. Typically, RAM stores only temporary information, for example, operating system or open apps, that are loaded into memory at startup. Its volume directly affects multitasking and device performance. The internal flesh memory of the phones is slower compared to RAM and ROM, but much faster than the external memory on the SD card. Therefore, many companies, including the iPhone, install a fairly capacious internal memory from 16 to 128 GB. MicroSD card provides an extension of the physical capacity of the internal memory. Basically, it provides storage for user data, including, videos, music, documents and app data. Articles often contain data on memory capacity without specification. Strictly speaking, this is incorrect, because Android system partitions reside in the same eMMC or UFS chip as the internal memory. Thus, the amount of memory available for rewriting is approximately 2 GB less than that specified in the specs.

Flash storage

ROM of modern smartphones use eMMC or UFS storage. Until recently, eMMC (embedded MultiMediaController) practically had no competitors in the segment of mobile devices. The latest eMMC 5.1 version was released in 2015, providing a reading speed of 250 MB/s and writing - 125 MB/s.

In 2016, Samsung first introduced UFS (Universal Flash Storage) memory based on the new operation principle that provides significantly faster read / write speeds. In particular, eMMC uses sequential organization of read / write processes (Half Duplex), while UFS implements them simultaneously (Full Duplex).

As a result, UFS is significantly faster and consumes less power. Today eMMC 5.1 is the most common for budget devices and mid-range smartphones. Accordingly, UFS is used for flagship devices. Their comparison among themselves demonstrates the huge advantage of UFS memory. For example, sequential read / write for UFS 2.1 reaches 750/143 MB/s vs 282/98 MB/s for eMMC 5.1. Moreover, Samsung Galaxy Fold, Note 10, as well as Chinese OnePlus 7 and 7 Pro, already use UFS 3, which works three times faster even compared to UFS 2.1.

As a rule, the specifications of models with UFS contain information about the memory type, which in this case is an indirect advertisement.

RAM

Gradually, companies expand the RAM of budget models from 2 GB to 3-4 GB, increasing their productivity for web surfing. The middle segment still uses 4-6 GB. RAM of some flagship models already reaches 12 GB. As before, companies use LPDDR (mDDR or Low Power DDR) memory. Their list includes: - LPDDR3 - in the budget segment; - LPDDR4 and 4X - middle and expensive models; - LPDDR 4X at maximum frequencies of 2133 MHz - flagship models. Samsung promises to introduce a faster LPDDR5 in 2020.

According to the company, its energy consumption will be reduced by 20%. Today, Samsung produces UFS moduls for their smartphones and also sells them to other companies, including LG, Huawei and HTC. Apple uses memory from different manufacturers. For example, iPhone 7 and 5S use memory modules from South Korean SK Hynix, iPhone 6S from Toshiba, iPhone 6 from SanDisk. Toshiba also supplies memory for Xiaomi and Meizu.

Conclusion

Today companies often combine different types of memory for smartphones because of cooperation with several suppliers at once. For example, Huawei P10 and P10 Plus can come with LPDDR4 and eMMC 5.1, LPDDR 3 and UFS 2.0, or with LPDDR 3 and eMMC 5.1. Of course, the company claims that their speed is identical. But the speed of UFS 2.1 and eMMC 5.1 are significantly different. In principle, this situation is typical for the smartphone segment. For example, Samsung in its flagship models uses Exynos chips or Qualcomm chips, and the iPhone 7 may have an Intel or Qualcomm modem. Of course, the memory type significantly affects its speed. But, on the other hand, these differences affect only downloading heavy games, for example, World of Tanks Blitz, or transferring large amounts of data to a PC. Therefore, expediency substantially depends on the price. As a result, many companies are in no hurry to install ultrafast memory on their models. For example, the flagship Xiaomi Redmi Note 7 Pro, Samsung Galaxy A70, Blackview BV9700 PRO, LG G8 ThinQ, and Huawei Mate 20 Lite still use eMMC 5.1. At the same time, the mid-budget LG G7 Fit, Xiaomi Redmi K20 Pro and Sony Xperia XZ2 Compact already use UFS 2.1. But, of course, at an equal price, models with UFS are preferable to smartphones with eMMC 5.1. This video offers a comparison of UFS 2.1 vs 2.0 vs EMMC 5.1. Read the full article

#BlackviewMAX1ProjectorMobilePhone #embeddedMultiMediaController #eMMC5.1 #FullDuplextechnology #LowPowerDDR #LPDDR5 #Smartphonememory #SmartphoneStorage #UFS2.1 #UFS3 #UniversalFlashStorage

0 notes

sparreaux · 7 years

Text

So I’ve had my computer for a few days and I think I can give a small review now, for those of y’all who are curious.

What I have is a Asus Transformer mini. It has a 10.1 inch screenand can be used either as a laptop or a tablet. The attachable keyboard and active stylus are included with the initial price. I got mine for somewhere around $250. It’s pretty damn light and thin enough for me to carry everywhere AND it’s got at least an 11 hour lifespan off the battery. I’ve heard 14 is possible. The keyboard detaches easily and switching between the two function of desktop vs tablet can be instant if you set it up that way.

For my purposes, I wanted the tablet for art and laptop function for everything else. The pressure sensitivity is great, though I found myself having to turn off the touchscreen to keep the cursor from jumping every now and again. (It does have an option to ignore touches when the stylus is in use, but it kept getting a little confused by my hand constantly touching it. Now it draws with even better control than my old HP. A few people have called it a surface mini, but I have no experience with any of the Microsoft Surfaces, so I can’t really make that call.

There’s 4GM of RAM and 128GB of eMMC, which is pretty night for a lightweight tablet. There is of course a mini SD card slot to help you out on that. And I was delighted to find there was an actual USB slot on here.

The only real con I’ve had is that this sucker IS on the slow side, but you’re getting a 2 in 1 for under $300 and that’s not shabby. A minor quirk is the touchpad’s sensitivity. i try to stick to the stylus or an external mouse.

Alright, that’s all I can think of, but if you have any questions, I’d be happy to answer them.

4 notes · View notes

dsrajawat · 5 years

Text

These days, you don’t have to pay large to experience a smart smartphone. Even if you’re penny-pinching, the budget contenders could prove an appealing worth. One brand that has made great strides with its “a whole lot for little” approach is Realme. Today, the brand has value offerings across the entire affordable and mid-range spectrum. There’s the Realme X2 Pro at the vanguard, the Realme C3 lies at the other extreme.

I’ve used the Realme C3 up and close for quite some time. And all the while, my quest was to see whether it cuts as a good enough daily driver. So, let’s see how it went about.

But before that, here’s a quick comparison of the key specs differences between the Realme C3 and its precursor.

Realme C3 vs C2 Price and Specification

Model Realme C3 Realme C2 Display 6.52-inch HD+ LCD minidrop fullscreen 20:9 aspect ratio 6.1-inch HD+ LCD minidrop fullscreen 19:5:9 aspect ratio Processor 2.0GHz, MediaTek Helio G70, 12nm chipset 2.0GHz, MediaTek Helio P22 12nm chipset RAM 3GB/ 4GB LPDDR4X 2GB/3GB Internal Storage 32GB/64GB eMMC 5.1 (microSD up to 256GB) 16GB/32GB eMMC 5.1 (microSD up to 256GB) Software Android 10 Realme UI Android 9 Color OS 6.0 Primary Camera 12MP (f/1.8, 1.25μm) (Macro 8cm) + 2MP (f/2.4) portrait, PDAF, 1080p@30fps, 480p slow-mo 13MP (f/2.2, 1.12µm)+ 2MP (f/2.4), 1080p@30fps Front Camera 5MP 5MP Battery 5000mAh (OTG reverse charge) 4000mAh Price

3GB+ 32GB: Rs. 6,999

4GB+ 64GB: Rs. 7,999

2GB+ 16GB: Rs. 5,999

3GB+ 32GB: Rs. 7,999

Also, here’s everything you get within the box.

Realme C3 In-box Contents

1x 5V2A Adapter

1x Micro USB Cable

1x Important Info Booklet with Warranty Card

1x Quick Guide

1x SIM Card Tool

1x Screen Protect Film

Realme C3 Review: Design, Build, and Display

Realme C3 sports the new Sunrise Design, which gets the name for its converging light effect. It looks as if the light beams are radiating from beneath the camera island. That said, it’s still recessed and both the Red and Blue paint jobs aren’t that flashy. But, I must say, I miss the polygonal effect which embellished the early-gen Realme phones. Besides the camera array, the rear rocks a realme logo as well.

The phone has a smudge-free frictional surface, which offers a nice grip. It’s lite and ergonomic thanks to an all-plastic body. Realme claims the phone is splash resistant, with tightly sealed ports. So, overall the device embodies an industrial build with ample attention to detail. This is important considering its price.

#gallery-0-25 { margin: auto; } #gallery-0-25 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-0-25 img { border: 2px solid #cfcfcf; } #gallery-0-25 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

C3 echoes the same side frame button arrangement as every other Realme phone since day one. You’ll find the volume rockers on the left while the power button sits on the right. The buttons are mushy and plasticky, but that’s to be expected with entry grade phones.

Moving forward, the frontier flaunts a familiar mini drop notched vista. Inside that notch resides a camera that enables Face Unlock. It works fine save for when you try it in a dull or dark ambiance. Not much to say there. But, the real kicker is the absent fingerprint sensor. That means if not for face unlocking, you will have to resort to PIN/Pattern/Password.

The screen here is alright for the price. It’s a 720P panel measuring 6.52 inches, with a 20:9 aspect ratio. It’s good to have that kinda real estate in this segment. That said, this is still a moderate-quality IPS LCD panel.

Realme C3 Review: Performance and Software

This is the portion of the review which you may call as a tasty trifle. Here’s how ( ° ∀ ° )ﾉﾞ

Realme C3 is the first phone to ship with MediaTek G70 silicon and Realme UI software. The former is a pretty powerful chip for handling your daily chores. It fared well in my Asphalt 9 and PUBG sessions. The graphics take a hit for sure with some jank and jitter here and there. However, nothing spoiled the sport for me. Likewise, everything from multitasking, app-switching, and navigation was nippy.

Speaking of navigation, I adore the Android 10‘s gesture-abled movements. There’s plenty to like about the new Android edition. On top of which, you have the Realme UI (review). For the first time, I felt like using the Realme software as it is. It’s a welcome update through and through. If you’d ask me to pick a bone with it, I would point at the remaining few bloatware. Rest, I have gone in-depth about the UI in my dedicated review of it.

This time around, Realme has stowed in more memory, both on the RAM and ROM front. You get to grab the device in 3GB RAM plus 32GB storage variant as well as a higher 4GB RAM plus 64GB storage option. You can max the storage configuration by up to 256gigs using the dedicated SD card slot.

I also run the popular benchmark tests and to my surprise, its scores were in an altogether different league. For instance, Realme C3 has fared better in Antutu benchmarks than pricier peers like Realme 3 Pro, Mi A3, Redmi Note 7, Samsung Galaxy A50, Realme 5 and Redmi Note 8. Here are the results –

#gallery-0-26 { margin: auto; } #gallery-0-26 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-26 img { border: 2px solid #cfcfcf; } #gallery-0-26 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Geekbench 5

3DMark Slingshot Extreme

3DMark Slingshot

Androbench

DRMinfo

PCMark

Realme C3 Review: Camera

Realme C3 wields a 12MP (primary) plus 2MP (depth) sensor duo at the back. To the front, we have the same 5MP selfie snapper as found in the predecessor. As a part of the new UI overhaul, the camera app also looks anew.

Coming to the real-world performance, I was quite astonished by some shots I managed to capture out of it.

#gallery-0-27 { margin: auto; } #gallery-0-27 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-27 img { border: 2px solid #cfcfcf; } #gallery-0-27 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

If you capture something in close proximity under a good amount of light, then the photos are sharable on social media.

#gallery-0-28 { margin: auto; } #gallery-0-28 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-28 img { border: 2px solid #cfcfcf; } #gallery-0-28 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

But, things get tricky when you distance yourself and the light is unfavorable.

#gallery-0-29 { margin: auto; } #gallery-0-29 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-0-29 img { border: 2px solid #cfcfcf; } #gallery-0-29 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Details are wishy-washy in both shadows, highlights and colors look pale.

The colors are far from natural. Look at the lifeless leaves.

Realme C3 is plagued by the same issues found in similarly priced phones. The details look washed out. The dynamic range is spotty, which means you have to live with crushed shadows and subdued highlights.

#gallery-0-30 { margin: auto; } #gallery-0-30 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-30 img { border: 2px solid #cfcfcf; } #gallery-0-30 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Low light photography would have benefitted Nightscape. Even without it, the photos are serviceable.

If you glance at the human subjects down below, the front and rear cameras have done a pretty decent job. But, mind you the camera does falter in exposure handling, face-tracking and even that portrait blur tends to eat into the subject at times.

#gallery-0-31 { margin: auto; } #gallery-0-31 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-31 img { border: 2px solid #cfcfcf; } #gallery-0-31 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

You can shoot up to FHD videos at 30fps and an option to go slo-mo at 480fps. They are okayish and nothing to write home about.

So overall, the optics are certainly capable of handling most everyday requirements, and it’s definitely better than it has any right to be.

Realme C3 Review: Audio, Battery, and Connectivity

Realme C3 has the stamina to pull through an ordinary day. In our endurance test, the 5000mAh battery ran for 8h 26min.

#gallery-0-32 { margin: auto; } #gallery-0-32 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-0-32 img { border: 2px solid #cfcfcf; } #gallery-0-32 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

And when the device begs for a charger, you’ll have to resort to a 10W charger. This is slow as a snail to refill the tank. Look, it’s no surprise, but more like a reminder for the budget. My real grievance is with the micro-USB port. I feel like its high time that even low-trim phones start coming with a USB Type-C.

And yea, Realme has thrown in a reverse charge feature too, in case you care.

The micro-USB socket is flanked by a 3.5mm headphone jack (I’m not one to take it for granted!) and a single speaker grille. The audio output is tiny without any texture.

The Dual-SIM phone serves its purpose as a phone with fine call reception. The person, on the other hand, too had no problem hearing my euphonious voice.

Amongst other things, you also get Bluetooth 5.0 with support for audio codecs like SBC, AAC, APTX, LDAC. (Nice!) You’ll appreciate these acronyms while listening over a wireless earphone.

Realme C3 Review: Closing Thoughts!

When you buy a budget handset, you look forward to the essentials. You want everything that matters and nothing that doesn’t. So, my review quest was to test out the performance, and see whether the overall offering is value-packed or not?

Yes, It is! I am fairly satisfied.

It’s given that a top-dollar item will give you the most phone. But it’s impressive when a phone hits the spot without costing an arm or a leg. Thus, being on a budget doesn’t mean you can’t enjoy a decent smartphone experience. The newly launched Realme C3 is inexpensive and still appears to tick most boxes. It is the first phone with the MediaTek G70 and the first phone to offer Android 10 for under Rs. 10,000.

Although Realme C3 is cheap as chips starting at Rs. 6,999, I appreciate the fact it didn’t stop me from doing anything that I wanted to do.

Pros

Respectable performance and UX

Battery mileage

Good photos under favorable conditions

Cons

MicroUSB

Audio

Camera fails under challenging light and long-range

Realme C3 Review These days, you don't have to pay large to experience a smart smartphone. Even if you're penny-pinching, the budget contenders could prove an appealing worth.

0 notes

androidtvboxreview · 7 years

Text

T95N Mini MX+ TV box Review By Android TV Box Review

T95N-Mini M8Spro or T95N-Mini MX+ TV Box, Power Adapter, Remote Controller, User Manual, HD Cable. As we wrote earlier, both models are available at attractive prices: $37.99 for T95N-Mini M8Spro and $30.99 for T95N-Mini MX+. It is worth noting that TV boxes are available in pocket-size so no problem TV Box takes with you to the office, school, a trip or somewhere where you want. As always, we recommend you to select TV Box with more RAM.

#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 25%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

T95N Mini MX+TV Box with remote

T95N Mini MX+TV Box Ports

TV Box visually is similar to the Mini M8S II. In addition to the typical Amlogic S905 which supports UHD 4K@60fps HW decoding, multiple formats including H.265 10-bit, H.264, AVS+ and also FHD 1080p @60fps HW encoding, H.264, T95N-Mini M8Spro has 2GB of RAM and 8GB of flash for data.

Where to buy T95N Mini TV box Review

You can buy the T95N Mini MX+ Firmware box from GearBest, Amazon or Ebay

Amazon UK

Amazon.com

Specification

CPU: Amlogic S905 quad-core cortex-A53 frequency 2.0G

GPU: Mali-450 5-Core GPU

RAM: 1GB DDR3

ROM: 8GB eMMC Flash

OS: Android 5.1

KODI: 16.0 Pre-installed and Play Well

Support 4kx2k H.265 Hardware Video Decode and 4Kx2K Output

Ethernet: 10/100M, standard RJ-45

SoC – Amlogic S905 quad-core ARM Cortex-A53 @ up to 2.0GHz

GPU – Penta-core Mali-450MP Up to 750MHZ, OpenGL ES 1.1/2.0 and Open VG 1.1 support

Memory – 2GB DDR3 (1GB RAM has T95N-Mini MX+)

Storage – 8GB eMMC flash + micro SD card slot (up to 32GB)Video Output – HDMI 2.0, AV Video Codec – 4K@60 Hz video decoding 10-bit HEVC and A

VS+ codec support; H.264 up to 4K 30 Hz

Audio – HDMI, AV

Connectivity – 10/100M Ethernet, 802.1

1 b/g/n Wi-Fi, Bluetooth 4.0

USB – 2x USB 2.0 host ports

Misc – IR receiver

Power Supply – DC 5V/2A

Weight – 90 g

Dimensions – 9 x 9 x 1.7cm

T95N Mini MX+TV Box Review Reviewed By Android TV box Review T95N Mini MX+ TV box Review By Android TV Box Review T95N-Mini M8Spro or T95N-Mini MX+ TV Box, Power Adapter, Remote Controller, User Manual, HD Cable.

#android TV box #review #T95N Mini MX+ Firmware box

0 notes

shinyquagsire23 · 6 years

Text

Nintendo and Executables, Emulation and Piracy

Edit (Nov 2 2022): This article contains some prior speculation and grumbling about Cemu, which is no longer closed source. Even prior to open sourcing, Cemu aided in documentation efforts for decaf. At the time though, contributions to WUT were solely done by decaf-emu and others.

While hanging around in the Citra and yuzu Discord servers this question (or some variant of it) has arisen several times, "Why was Cemu/yuzu able to develop so quickly?", and while there's some fairly obvious answers with regard to Cemu's actual development strategies (open-source vs closed-source, Patreon, etc) and some misconceptions with yuzu and the Switch I feel like these questions are a good opportunity to write on some of the factors which might play into acceleration in emulation development and reverse engineering efforts in general while also going over some of Nintendo's "DRM" and its relationship with emulation and piracy.

Also before anyone gets their jimmies rustled over piracy I think it goes without saying, my intentions talking about piracy in this article are not an endorsement of it, I just think the requirements and methods between Nintendo’s operating environments are interesting.

QUICK BACKSTORY

Just to give a quick rundown on credentials and I suppose to maybe give an idea on my familiarity with Nintendo stuff. I did some super basic GBA ASM hacking starting around 2010 or so but I started hacking ‘modern’ Nintendo consoles with the 3DS in late 2014 when the homebrew launcher for ninjhax was released. Somehow managed to implement a kernel exploit based on reverse-engineered Gateway code (though firmlaunchhax is relatively simple as far as exploits go), joined up with the rest of KARL3DS (later SALT), did some CFW/vuln stuff for 3DS for a bit, tried to bootstrap a polished Wii U CFW joint with SALT, TiniVi, SciresM and others (it didn’t totally flesh out but I did personally get native homebrew in a decent state via the Wii U Toolkit/WUT), joined with ReSwitched shortly after the Switch launch, later was kicked out, messed with Switch HID/Joy-Con stuff, found shofEL2 with some people independently, started a bit of a fuss with Linux stuff and Real Hackers and now I just do this stuff for fun I guess.

3DS ARCHITECTURE

Quick rundown on the 3DS: The kernel, codenamed Horizon, is a microkernel capable of handling multiple processes at once, along with threading, memory management and communication for those processes. Horizon and all 3DS games/applications run on the dual core (quad core for New 3DS systems) ARM11 processor in the SoC. Additionally, the 3DS has an ARM9 security coprocessor responsible for dealing with eMMC/gamecard protocols, filesystem access, signature verification, encryption, and other things. So if an application wants to access an encrypted content container on the SD card, it asks the FS process for content in that container, FS asks Process9 over PXI if it can get access to that container, Process9 checks permissions in the process exheader to see if permission to this container is granted, if it is Process9 will handle decryption and pass decrypted data from the container back to FS and back to the application. To throw in an additional example, if an application wants to decrypt a Mii QR code it has to scan the QR code, get the data, pass the data to the APT service process to ask for it to be decrypted, APT hands the data to PS and asks for it to be decrypted, PS asks Process9 over PXI to decrypt the data, then the data gets decrypted and it gets passed back to PS, back to APT, and then back to the process which needed a Mii QR decrypted. Granted, I might have missed a step or two in there and I've simplified things a bit, but this is effectively the way data gets passed around within their system.

APPLICATION ARCHITECTURE

The main container which holds executables on 3DS is the CXI container, which is mostly seen on the SD card and NAND under the .app file extension. For SD cards, these files are encrypted with a per-console key, and on NAND there is an encryption layer over the entire CTR OS FAT partition instead. After the first layer of crypto on the file we get to see a signature over the CXI header, the header itself which includes some metadata, ExeFS offsets and lengths, RomFS offsets and lengths, extended header offsets and lengths, and hashes over most of the remaining content such that the signature hash going over the header also covers any and all content within the container. As such, all content in this container is signed and verified.

ExeFS is the file container which contains the code binary along with the application's banner, icon, and metadata (app strings, region specifications, etc), and RomFS is the file container which contains any and all game data that isn't just compiled into the executable. These containers can be mounted by the SDK and accessed by applications depending on permissions. Going deeper into the actual code binary though, the main executable is entirely contained in the ExeFS file ".code", which is a single compiled block which contains the applications .text, .rodata, .data, and .bss. The offset and length of each of these sections is contained within the exheader pointed to in the CXI header, and stack memory is allocated at 0x10000000-<stack size specified in exheader> (stack memory for other threads, however, is usually allocated from the heap). Heap memory is mapped using system calls to 0x08000000 or 0x30000000. While ExeFS and RomFS can be accessed by most applications, the exheader can only be retrieved through the Process Manager service on the ARM9 via PXI and is mostly used by the loader service on the ARM11 and on the ARM9-side to validate permissions.

As far as actually interacting with the hardware goes, SDK code is always linked statically into the code bin, and SDK code is what actually handles heap management, filesystem mounting, and other things. For hardware and OS interaction, the 3DS uses several dozen system services running as their own processes, and the main application does IPC queries through system calls which translate the parameters and addresses between processes. To get a bit more specific, the main application will get a handle for "srv:" from a system call, and this handle will be used to get handles for other system processes, dependent on the application permissions given to the service manager which manages "srv:". If an application needs to talk to the GPU, it gets a handle for the gsp service from srv and from there will use IPC calls to ask the gsp service to send commands to the GPU hardware. If an application wants to install an application, it needs a handle for "am:u", and *if the application has permission to talk to this service*, a handle will be returned and the application can ask "am:u" to send a file handle to send IPC write requests to write CTR Installable Archives (CIAs) to so that "am:u" can handle the actual install. Side note, this allowed 3DS to create CIAs from eShop contents at runtime since CDN content was identical to what would be copied onto the SD card/NAND, albeit with a layer of crypto on top.

REVERSE ENGINEERING

The difficulty in reverse engineering, however, comes as a result of whatever being beyond the IPC layer being largely a black box: there are no symbols, if you're lucky you might get strings, but otherwise you're on your own if you want to know what command 7 in some service does. Without being able to decompile the service, you might be able to fuzz command 7 and figure out how many arguments it wants, what kind of address or handle translation it expects, etc. But at the end of the day you've only got guesswork and maybe some usage cases in the application. With access to decompiled service code, things get better, but not too much better. There are still no symbols and if you want to know what a command *actually* does you need to document a significant amount of decompiled code.

There is one exception, and it is an extremely rare exception on 3DS: 3DS *does* have support for dynamically linked libraries in the form of CROs, or CTR Relocatable Objects, stored on the application RomFS. CROs can be dynamically loaded, linked and unloaded and unlinked to and from an application's memory map at runtime. Since the ExeFS code bin is just a straight binary, a file called static.crs is stored along with CROs to describe the layout of functions in the static code bin, and optionally along with that, symbols can be described in this file. Effectively it acted as a shim for taking .code from a blob to a linkable ELF-alike, and at a basic level, CROs effectively function as ELFs except what would be every ELF section has its offset specified in the header along with the additional code signing measures which reside there. While not many games did ship with symbols, there were some big games like Pokemon Sun and Moon and Smash for 3DS which ended up shipping with a significant portion of their application’s symbols, making reverse engineering at least slightly easier. Some games like Steel Diver ended up shipping with ELF files in its RomFS which just had all symbols outright, so it's not all doom and gloom, but you're still at the mercy of software updates and what functions applications actually end up using unless you reverse things by hand in the relevant services.

EMULATION

As far as what an emulator like Citra actually emulates, it largely just emulates system calls and any IPC calls sent to other processes will be handled in high-level emulation rather than emulating the system processes on a lower level. This is slowly changing of course, because in order to emulate launchable applets such as the software keyboard, emulating multiple processes is required. The difficulty largely comes from emulating the (often strange) PICA200 GPU, along with emulating threading behavior and other syscall behavior of the 3DS kernel. Even with the wealth of reversed functionality, there are still several services with undocumented error behavior and other behaviors which have yet to be discovered.

I WANT TO PIRATE ON 3DS - WHAT ARE THE SECURITY IMPLICATIONS?

Practically, piracy on the 3DS requires full control over both the ARM9 and ARM11 cores. Because applications are bound to the signature verification on the ARM9, and also because all 3DS binaries are one solid lump of nonrelocatable code, it's not easy to pirate games even with arbitrary code execution. What specifically makes it difficult to pirate games without ARM11 kernel access (given gspwn, which allows any code to be overwritten) is being bound to the memory permissions of the application being taken over, one application might start read+write data sections at 0x120000 while another starts it at 0x240000, so it becomes a game of getting memory permissions to match (or alternatively, finding an application which sufficiently-sized sections and then statically recompiling the code to match those bounds). On top of that, all accesses to RomFS have to be remapped to another filesystem (or over network), which is possible as seen with HANS and *hax which transfers SD card file handles from applications which have access to the SD card (home menu) to other applications. Additionally, the permissions of the base application must match the to-be-pirated application, or the to-be-pirated application must have its code patched to no longer require permissions outside of the scope of the base app.

With ARM11 kernel, the issues of memory mappings are less of an issue since system calls can be granted to remap sections as appropriate or even spawn processes from scratch, and the issue of service permissions is lessened because the service manager which checks permissions can be patched to give permissions to all services. However, RomFS is still tricky to deal with and it would still require some sort of loader to set up and patch the application while avoiding the ARM9. Alternatively it is possible to install a select group of applications which came bundled on certain special-edition 3DS systems which were signed with global system keys instead of being tied to any one specific system via tickets.

With ARM9 kernel access, signature checks can be dropped entirely, allowing applications to be installed to the home menu as usual.

WII U ARCHITECTURE

With the Wii U, things get a lot less... nice. The Wii U has a quad tri-core PowerPC processor along with an ARM9 security coprocessor (sound familiar?). Cafe OS, or COS, is the main component running on the PowerPC for Wii U, and much like the Wii, IOSU (internally just called IOS) runs on the ARM component. Comparing the Wii U to the 3DS, IOS basically runs most if not all of what would be service processes on a 3DS, as far as hardware goes the PowerPC effectively only gets to talk to the GX2 GPU and the audio DSP (there's a bit more exposed than that but those are the big ones I can recall). Filesystem access, USB, Bluetooth, network drivers, input drivers, eShop/friend code/BOSS/account https protocol, etc is all handled in IOS. The PowerPC pretty much *only* handles games and applications.

COS doesn't support any real application multitasking, instead it has a single process running at once with multiple processes loaded into memory to be switched to as appropriate. The two main memory areas relevant to this are MEM2 which is used for storing executables and heap, and MEM1 which is used as video/framebuffer memory. If an application wants to "multitask" over to the Home Button Menu (HBM), it has to be waiting for a signal from ProcUI telling it that the home button has been pressed, and on that signal the application has to unload all of MEM1 and prepare its threads to wait (with the exception of Core 2, which is allowed to continue executing while multitasking in HBM, web browser, etc). If a process wants to intentionally switch over to another application, it has to ask sysapp to signal a launch which will trigger ProcUI signaling the application to close up and exit. If an application doesn't signal to ProcUI that it's ready to switch to another process, COS will just never switch to another process.

The Wii U filesystem is a lot closer to *nix in that you can mount/link different devices and folders to the filesystem. The Wii U has three main storage mediums, SLC (a dual-bank 512MB NAND on the board, with one bank used for Wii U and one for vWii), MLC (the main 16/32GB eMMC chip), and USB storage devices. IOS mounts each of these to /vol/storage_slc/, /vol/storage_mlc01/, and /vol/storage_usbXX/ respectively. Titles can either be installed as user programs which can be deleted or system programs which cannot be deleted in the settings app, and the only real difference as far as installation is that one gets installed to the `usr/title/` folder on a device and one is installed to the `sys/title/` folder. Interestingly, the main filesystem is actually accessible to the Wii U, as opposed to 3DS where applications are largely sandboxed away from the raw filesystems. There are, however, permissions checks to prevent applications from meddling with files they don't own: The Wii U filesystem has a full RWX owner/group/everyone permission system for files which specifies which files belong to what app, with groups to allow access of files to other applications or if the file can just be accessible to everyone. So if a title wants to access content from another title, it can access the file outright if it has permissions for it. For some of my GX2 programs I ended up doing a chmod to change the permission of a shader in the Health and Safety application so that I could access it without having to redistribute it in my application. So with permissions changed I could just open "/vol/storage_mlc01/sys/title/00050010/1004E100/content/shader/texture2D.gsh" directly.

APPLICATION ARCHITECTURE

A title consists primarily of three folders on the filesystem: code/, content/, and meta/, each of which gets mounted to /vol/code/, /vol/content/ and /vol/meta/ respectively so the application doesn't have to step through the actual filesystem to open its files. Ownership and group permissions for the files in these folders are set at install time, and all files in the original install content containers are extracted onto the filesystem. The running owner/group is determined by two XML files in code/: app.xml and cos.xml. app.xml specifies the OS version the application can run on (ie updater titles have the updater COS TID here), the group ID it runs with, and the SDK version it requires, the application type (update vs app), etc. cos.xml includes all of the permission masks for each IOS process group, whether the application has a JIT area, the maximum code area size, stack sizes, and other bits. So if an application wants to be able to access the SD card, it needs the appropriate permission bits set in cos.xml, or if an application wants to install other applications it needs the appropriate MCP permissions.

/vol/code/ also contains the application RPX and any additional RPLs, with the RPX being the main application and RPLs being dynamically loaded libraries. RPXs/RPLs share the same format and they are effectively ELF files with zlib compressed sections along with import/export sections for linking with other RPLs. RPLs can be loaded and linked dynamically at runtime or automatically when the RPX/RPL is loaded using .fimport_<RPL name> sections. All SDK code is held in RPLs on SLC, so most applications are either just an RPX, or an RPX with some extra libraries like webkit, curl, cairo, openssl, zlib, etc held in RPLs. As an added note, files on SLC actually end up being cached in a ramdisk by IOS to improve load times, though this was actually the reason some CFWs like Mocha ended up having to redirect /vol/system/config/system.xml to /vol/system/config/syshax.xml to prevent Haxchi bootloops, system.xml ends up getting cached too and the ramdisk is not cleared on soft reboots (this ramdisk can also cause issues in running higher/lower firmware versions with NAND/MMC->SD redirection since files from before the reboot will linger into the next COS 'session').

LET'S DIVERT A BIT - TITLE INSTALLATION AND VERIFICATION

Up to this point I haven't actually mentioned anything about title verification, and that's because it gets a bit weird on Wii U. To start, the title "package" format is similar to what you would actually see as an installed 3DS title, there's several %08x.app files, several %08x.h3 files, along with a title.tmd, title.tik, and title.cert file. The ticket and the cert end up going elsewhere on the filesystem, however title.tmd and an additional title.fst are kept in code/ to validate files. The .app files can be either encrypted with the title key encrypted in the ticket with the Wii U common key, or they can just be decrypted. 00000000.app always contains the FST which describes the files and folders stored in the rest of the .app files (a single .app can contain multiple files in the resulting title filesystem). The FST is also used on disks to specify which sectors go with which files, and the FST found on disks will match downloadable games.

The TMD contains a signed header specifying the number of contents, and a hash over the content chunks outside the header, which contains information describing each .app (is it encrypted, what type of content is it, what is the hash of the .app file). What effectively ends up happening for content verification is that any files which need to be verified get their own .app file so the hash in the TMD will match the hash of the file on the filesystem. Files which are *always* validated include anything in code/, along with select other files, and this is consistent with all applications. Were it not, you could simply replace an RPL and get code execution easily.

Since titles are kept extracted as files on filesystems instead of one big verified chunk like on 3DS, this opens some interesting potential attack vectors. The most obvious vector, and the most known, being contenthax, which allows unvalidated content in the content/ folder of titles to be modified at-will. With Haxchi, this is used to get trivial ROP in Virtual Console games which have the JIT area enabled. Some apps such as the browser also include html files, potentially opening up vectors for offline WebKit vulnerabilities (provided they're stable enough that the browser doesn't end up bricked). Additionally, applications which scan the filesystem for files are able to have files added, bypassing any potential signature checks. This doesn't, however, work for any RPX or RPL files in code/ or on SLC, since loaded RPLs always have their existence in the FST checked along with their hash in the TMD having to match. The benefit of less validation of course comes in loading speeds and better disk durability since slight errors have a lower chance of hitting code and a greater chance of hitting content which is not verified.

LOADER.ELF

Back to executables, RPL and RPX loading is done in COS by loader.elf, which is loaded on startup by the PowerPC kernel. loader.elf is pretty much the absolute bane of my existence and I really don't understand why Nintendo felt the need to include an ELF loader in kernel just to load in a much worse ELF loader, but to say the least it does an awful job of parsing RPLs. Luckily it has debug output accessible from IOS which actually specifies what it didn't like about the RPL it just tried to load. RPLs are effectively ELF files with compressed sections and import/export sections which allow them to link to other RPLs at load time. If an app wants to load functions from proc_ui.rpl, it has to include a .fimport_proc_ui section and the functions it wants to import specified in that section. If the functions don't exist, loader.elf will complain and refuse to load. If the system cannot find proc_ui.rpl in code/ or in the SLC OS libraries, it will also refuse to load.

Where RPLs become a bit of a pain point for homebrew and GCC is mostly in loader.elf; getting GCC ELFs into the RPL format is actually a fairly significant challenge. For a start, sections are expected to be written into the RPL in a particular order: Section CRCs and FileInfo are written first, then .rodata and .data, then imports/exports/symtab/strtab, then .text, and then relocation data. The list index order of sections also matters, CODE sections must be first, then DATA, then relocations, then imports, and then strtab/symtab/etc, with CRCs and FileInfo at the end. If any of these are incorrect, loader.elf will not load the RPL. Rodata must be marked as RW. Writable. There is no negotiation, it doesn't make sense, but loader.elf will refuse to load an RPL if rodata is not marked as writable. Every one of Nintendo's RPLs has .rodata marked as RW. All sections have specific alignments expected. A tempSize value is stored in FileInfo, presumably so that loader.elf knows how much RAM it needs to allocate to hold relocation data for linking. Except it doesn't use it, it just calculates the value from the section table and uses its calculated value to scrutinize your tempSize so that it can avoid loading the RPL.

As if loader.elf being extremely picky about ELF layout wasn't bad enough, Wii U's relocations are a massive pain to deal with. The Wii U does not use any sort of GOT (nor does it support it), and loader.elf only implements a limited subset of relocations: ADDR16_HA, ADDR16_LO, REL24, and ADDR32. R_PPC_RELATIVE is not supported, so for every R_PPC_RELATIVE relocation GCC generates it must to be converted to R_PPC_ADDR32 instead. Even more irritating, GCC likes to create R_PPC_RELATIVE relocations to completely different sections than the section the relocation is being operated on even though sections are supposed to be individually relocatable, so each of these relocations must also be converted to ADDR32 and either a symbol index or a memory section reference ($TEXT, $DATA) plus an addend. Even more amusingly, GCC would also create relative jump tables in .rodata (ie each entry is the distance from that .rodata address to .text), and these relative jump tables didn't even have relocations written in so rodata isn't actually able to be relocated away from text. What ends up happening is that since .rodata ends up in $DATA memory relocated completely separate from $TEXT, the calculated distances no longer are accurate. The only solution then, of course, is to lump .rodata in with .text so the relative offsets between .rodata and .text can be guaranteed.

REVERSE ENGINEERING AND EMULATION

Now that the nitty-gritty details on RPLs are out of the way, what's actually kind of interesting about Wii U as far as emulation goes resides entirely in the way Nintendo decided to set up RPLs. On 3DS, all SDK code is compiled into code.bin statically, and code.bin is always located at 0x100000 in the process map. Names and locations of SDK functions cannot be easily gained on 3DS, so the minimum option for emulation is emulating down to the IPC layer. With Wii U, all SDK code exists in RPLs, all SDK RPLs have symbols for each function which can be imported into applications, and there's basically no real IPC setup at all (except between the ARM's IOS and PPC's COS, but this is mostly handled at the SDK level and not by applications). This is a *huge* deal for emulation and a big contrast between 3DS and Wii U, because rather than having to guess what an IPC call does and what arguments it takes and dealing with translation of handles and such between processes, Wii U has every SDK function name laid out by design. The only guesswork remaining is what arguments every library function takes, and how the data actually gets handled. This also means that the likelihood of Wii U SDK materials being useful for emulation is much higher, since SDK headers would specify what arguments every RPL function takes, along with enums and struct definitions, and unfortunately without source code it's unlikely that the integrity of an emulator like CEMU can actually be gauged.

Just because I find it a bit interesting, and it's a decent contrast to Switch/3DS, the IPC interface between COS and IOS is actually an IPC shim for their ioctl interface. Every IOS service has a /dev/whatever device and the actual IPC commands themselves are your usual file operations for ioctls (open, close, read, write, seek, ioctl, etc). There's also a bit of permissions stuff so that processes can't poke interfaces they don't have permissions for but I just thought it was worth mentioning since Nintendo never really returned to this whole *nix-alike idea later on.

I WANT TO SAIL THE SEVEN SEAS ON MY WII U - WHAT ARE THE SECURITY IMPLICATIONS?

Practically, the Wii U only requires PowerPC kernel to pirate games. On 3DS this was a similar case, but Wii U handles most of services and permissions on the ARM-side in IOS, so why doesn't this cause any issues? Well, the issue comes down to the ease of relocation and skirting permissions. Much like the home menu on 3DS provides SD card access for *hax-based homebrew, on Wii U Mii Maker has SD card access in order to save QR codes to the SD card, and given PowerPC kernel access it is possible to take over this application and use that SD card access. Games such as Smash 4 also provide SD card access for screenshots. This application takeover ends up being critical as far as providing permissions goes.

The second part of Wii U piracy lies in loader.elf. While the PowerPC portion is more than capable of reading RPXs from discs/MLC/SLC itself, the reading is actually done entirely on the part of IOS's MCP process. Effectively what happens is once the permissions of the incoming application is established in IOS (these permissions being from the XML files in code/), loader.elf asks IOS for an RPX or RPL. MCP in IOS will check each of its valid RPL paths for file of that name in either SLC (for SDK RPLs) or the code/ folder, and if there is a valid RPL it begins to send it over, and loader.elf will buffer the RPL and load it. If loader.elf is compromised, this can lead to an attack where IOS loads in and believes an application like Mii Maker or Smash 4 is being loaded, but loader.elf can merely discard all the data being sent and load in its own RPX from the SD card. This RPX then runs under the context of what would have been Mii Maker or Smash 4, and because loader.elf is already compromised, mounts such as code/, content/ and meta/ can merely be avoided by patching all filesystem functions to redirect to the SD card since the applications being taken over have access to the SD card. Permissions issues can also be patched out effortlessly, since RPLs are relocatable and aren't particularly constrained. This is why loadiine is able to work by only taking over the PowerPC and not the ARM security processor.

SWITCH ARCHITECTURE

The Switch is probably the most interesting of Nintendo's modern consoles, mostly because it's the Hot New Thing but also because internally it ends up being an interesting synthesis between 3DS and Wii U ideals, usually (but not always) picking the best parts from both. To start, the Switch runs on a variant of Nintendo's Horizon microkernel, though it isn't quite the same as 3DS since it has been rewritten. Internally, it is dubbed Horizon OS, often abbreviated HOS much like Wii U's Cafe OS was COS. At the Switch's core is the Tegra X1, giving the Horizon kernel a 64-bit quad-core AArch64 processor to operate on, along with a TrustZone implementation to use for security. Much like 3DS, all hardware drivers and OS details are handled in their own separate processes, with many of the process being very similar to 3DS but, again, are rewritten. IPC in usage is similar to 3DS but the actual structure of IPC calls has been revamped and improved, with different descriptors for data going into another process, coming from another process, or for instances where data should be sent from one process and then modified and returned by the target service. Additionally, for instances where a service will require additional memory to operate or larger amounts of memory should be transferred, shared memory syscalls have been revamped to allow for different types of transfer memory and shared memory. For instance, the nvservices driver (a service which really is just a shim for NVIDIA's usual GPU drivers) requires that applications turn a chunk of its own memory into transfer memory so that a handle for that memory can be passed for nvservices to actually operate with. As such the application ultimately controls how much memory to use for graphics and all memory limitations can be placed on the application itself rather than having a complicated setup between the privileged processes, nvservices and the running application to determine allocation amounts.

As far as security goes, the critical difference between 3DS services and Switch services is that just about all of what used to be handled by 3DS Process9 has been moved into the respective services in Horizon; TrustZone works pretty much exclusively with crypto secrets and runs on the same processors as everything else (though most operations will only take place on core 3 specifically). By keeping all sensitive crypto secrets in TrustZone but allowing HOS to operate with content-specific keys, the filesystem service can utilize ARM64 crypto extensions and talk to devices directly, reducing the overall IPC overhead for faster load times and performance.

Lastly, given the recent shofEL2 vulnerability dropping, I feel it would be good to also go over the boot process of the Switch just as a general overview. TX1's boot starts on the BPMP, a small ARM7 responsible for spinning up the rest of the cores on the device. It is also responsible for managing low-power sleep modes to an extent. I'll avoid going too much into detail since https://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html covers things a lot better, however you can stop reading as soon as the boot ROM jumps to the bootloader since that's where Nintendo gets funky. Nintendo's package1 is the first piece of code loaded after bootROM, and this is stored on the eMMC boot partition bank separate from the general-use 32GB partition bank. package1 is responsible for decrypting itself and checking fuses, showing error screens, loading package2 from eMMC into memory, (formerly) showing the Nintendo logo, and starting the CCPLEX 64-bit A57 processors into TrustZone which would then verify and decrypt package2 and then move to EL1 in order to execute the kernel. Because of the diversity of ARM64 processors, TrustZone also handles the PSCI v1.0 protocol responsible for power state management for shutdown, rebooting and sleeping.

APPLICATION ARCHITECTURE

Applications are primarily stored as NCA files, with files on NAND being stored outright and SD files being encrypted with a NAX wrapper (although still retaining the NCA extension). Unlike 3DS, NCAs generally only contain one type of content per archive: program code, program control data, program metadata, or program content. For content and metadata, a RomFS/PartitionFS partition will contain the contents for that NCA, and for code, a PartitionFS is used to specify individual files which are part of the NCA. All of these details are handled by the fs process and are not exposed to the running applications and services.

Similarly to Wii U, NCAs can either reside as a system app on the SYSTEM partition of eMMC or as a user app on the USER partition, though on Wii U this separation was only done via folders on each device but the idea is the same.

For code NCAs, there are two variants of program files. For services, there is a single main file and a main.npdm. For applications, there exists a main, main.npdm, rtld, sdk, and optional subsdkX files. Except for main.npdm, all of these files are NSOs. Pulling from some of the better ideas of Wii U and 3DS, NSOs specify offsets and sizes for text, data, rodata, and bss sections in one big structure up front with offset 0x4 after the NSO text section containing a pointer to what is the equivalent of an ELF's .dynamic section to specify relocations, symbol tables, and other metadata. Much like the Wii U, all SDK components reside separate from game code in the sdk NSO, which provides higher level functions and a layer of abstraction between what developers actually use and the underlying IPC calls sent out to services.

Unlike 3DS and Wii U, Switch executables run in a randomized address space, and as such are required to be able to relocate themselves and link themselves to other loaded NSOs at runtime. With SDK apps this is handled from the rtld NSO which is based on musl. Also in stark contrast to 3DS CROs, Switch NROs are also held to this expectation and unlike 3DS, doesn't require loaded code to be modified for linkink to the main executable since everything just has a GOT and can be set up with rtld. This does mean though that sections are not separately relocatable like on the Wii U since there's an expectation of having all the sections for any one NSO/NRO in the same block of addresses. Once an executable is relocated, setup typically involves asking the kernel for memory, requesting a service manager (sm:) handle and then going through the setup for filesystem access, input sharedmem, video, and so on. Like 3DS, the service manager uses ACI permissions to determine if it should give handles to processes when requested, though prior to 3.0.1 if you didn't send the initialize command it would just give you any service handle you asked for.

main.npdm handles permissions exclusively (as opposed to the 3DS where the exheader also managed code sections), and the file itself is signed individually with separate keys from the NCA. However, there is actually a slight bit of unsigned leniency: Application permissions are defined twice in the file, once in the ACID header and once again in ACI, with the ACID header being verified and ACI unverified. The ACID header defines the min/max title IDs, the maximum file permissions, the maximum service permissions, the maximum kernel permissions and a few other flags. This way Nintendo is able to sign ACIDs with the absolute maximum permissions normal applications should have and the ACI portion is only able to go up to those maximum permissions but isn’t required to actually give out those maximums. The real benefit, I’m assuming, is that development units cannot merely sign themselves higher permissions; the keys to do that remain with Nintendo at all times. As far as retail applications go it doesn’t really make that much of a difference since NCAs are already signed anyhow.

Some NCAs can, however, contain other data. Program metadata and icons get their own NCA, and update data has its own NCAs. While NCAs have their own signatures internally, their naming scheme also is a large part of their verification; each NCA is named after the hash of its contents, making verification for corruption (given a filename) as simple as hashing the file and comparing to the name. Since the NCA magic is only visible after decryption the files tend to look like garbage regardless of corruption, so hashing is a decent check. It also makes it impossible to guess an NCA’s filename on Nintendo's CDN, preventing early access of game contents until the CNMT NCA indexing all a game’s contents is updated (and the hash of *that* is given by eShop servers)

REVERSE ENGINEERING

Reverse engineering on Switch, as it turns out, is actually much easier than it was on 3DS and maybe at times is as easy as Wii U, but there are definitely areas where work is still required. On version 1.0, many services actually contained a wealth of symbols, but often times it feels like symbols aren't entirely complete, however where symbols were lacking there was usually a slew of asserts which would not only provide function names, but variable names as well.

Additionally, since the sdk NSO is a separate linked binary with its own symbols for everything an application could want to call (and since all IPC calls originate from the sdk NSO) it's much easier to isolate and document functionality. Though, it's worth noting that system applets statically link the sdk NSO into the main application in order to save space and possibly keep symbols to a minimum when reversing things like web applets.

EMULATION

Switch emulation is actually sort of interesting, similar to the 3DS there's a layer of mystery between a lot of Switch IPC calls, however since the kernel is based on and functions very similarly to that of the 3DS, it has allowed emulators like yuzu to reuse components from Citra pertaining to syscalls and (some) IPC. However since the sdk NSO is separate, it is also possible (in theory) to just hook those SDK functions and opt more for a Wii U-style emulation approach of emulating the SDK behavior. Most emulators have, however, opted for the lower-level emulation approach which is probably a good thing in the long run anyhow.

The wealth of symbols and strings found in Switch services has made reverse engineering them for emulation much easier, and the more modern GPU architecture paired with projects like nouveau has made quicker work in getting shaders decompiled and emulated as opposed to the mystery chip that was the PICA200. Contrary to popular belief, however, there is not much else about the TX1 being a “generic chip” that actually helps much with emulation, maybe with the exception of understanding some driver behavior better because of the TRM.

I WANT TO PIRATE ON SWITCH - WHAT ARE THE SECURITY IMPLICATIONS?

Practically speaking, piracy on the Switch doesn't strictly require TrustZone access at all, since it doesn't really handle all that much except for crypto secrets, and given the right vulnerabilities it's likely that even kernel isn't strictly required. Since Switch code is relocatable it's also much more flexible with where it runs, meaning that theoretically something like a JIT area could be enough, but practically there are the same restrictions as 3DS with services and RomFS. However, with Switch even a DMA vulnerability is a lot more flexible; since ASLR is in play all that is required is a larger .text section and a larger .data section, and then NSOs can just match the .data section starting points and hook the .text start and it will relocate itself to work from that location. And again, RomFS access would need redirection in order to not attempt accessing the original RomFS.

Given kernel access (or probably even just fs ROP), it's more than possible to just have fs to load game contents from the SD card as has been seen with the LayeredFS piracy (which has an uncanny resemblance to loadiine it I'm being honest). In theory it would also be possible to do this sort of MiTM for modding RomFS files from a core process (or smhax) using sm reregistration and some ROP but it would be more effort than it's worth by this point.

#3ds #wii u #nintendo switch #hacking #emulation #drm

5 notes · View notes