5 ms·
A9ChipSource: small open-source iOS utility to identify A9 foundry
- sikhnerd 11y agoI was curious what the readme was referring to, this[0] apparently is the macrumors post and tool[1] this is a response to. [0] http://www.macrumors.com/2015/09/29/a9-chip-split-tsmc-samsung/ http://www.macrumors.com/2015/09/29/a9-chip-split-tsmc-samsu... [1] http://demo.hiraku.tw/CPUIdentifier/ http://demo.hiraku.tw/CPUIdentifier/
- userbinator 11y agoI haven't done any iOS development before but is there any real reason why a tiny app with what seems to be ~100 lines of code needs to be split into several small files with even fewer lines in them? https://github.com/WDUK/A9ChipSource/tree/master/A9ChipSource https://github.com/WDUK/A9ChipSource/tree/master/A9ChipSourc... As far as I can see, the actual work is performed by around 5 lines of code in this file, which reads a configuration value, performs two string comparisons, and outputs to 2 text fields: https://github.com/WDUK/A9ChipSource/blob/master/A9ChipSource/ViewController.m https://github.com/WDUK/A9ChipSource/blob/master/A9ChipSourc... In other words, is this level of verbosity/"fluff" typical of iOS apps?
- melling 11y agoAppDelegate.m and main.m are boilerplate. They are generated by Xcode when you create a new project. Often you don't change them. The ViewController is where you should start examining the code. Of course, you have the .h files too. With Swift these go away so there's fewer files. Finally, you can do scripting that doesn't have any boilerplate: http://www.h4labs.com/dev/ios/swift.html?age=10000&q=scripting http://www.h4labs.com/dev/ios/swift.html?age=10000&q=scripti...
- mfkp 11y agoMost of what you see is the boilerplate of generating a new iOS app. You're right, all of the interesting code is in ViewController.m, and if this were extracted to a library it would be much smaller. I think the point of this repo is a demo app that you can build and run on your phone to find out which chip manufacturer you have.
- ctdonath 11y agoThat's not much verbosity/fluff. It's the typical default auto-generated code files; basically the author said "new project" and filled in a few lines. No need to hand-optimize this into minimum files. ETA: With some cut-and-paste & removing stubs, and preserving the storyboards, the whole thing can be reduced to 20 lines in just main.m, smaller if you shift into "obfuscated objective-c" mode.
- WDUK 11y agoExactly, I spent less than half an hour writing this up, and wasn't aiming for the lowest LOC possible. This is all mostly boilerplate.
- deleted 11y ago[deleted]
- mnem 11y agoA quick port to Swift: https://github.com/mnem/SwiftA9ChipSource https://github.com/mnem/SwiftA9ChipSource. The functional bit is in https://github.com/WDUK/A9ChipSource/blob/master/A9ChipSource/ViewController.m https://github.com/WDUK/A9ChipSource/blob/master/A9ChipSourc.... Objective-C isn't too bad. I've certainly had more boilerplate to deal with on various other platforms. In terms of names, it is verbose though. It's one of the things I really like about it.
- phire 11y agoI should have come to the comments before trying to work out which file the functional code was in.
- melling 11y agoHow do you do this in Swift? CFStringRef val = (CFStringRef)MGCopyAnswer(CFSTR("HardwarePlatform")); NSString* chipIdentifier =(__bridge NSString * _Nullable)(val);
- terhechte 11y agoTheoretically just: let u = MGCopyAnswer("HardwarePlatform") However, the problem is that MGCopyAnswer is a private method, and thus you have to define an interface for it. You can't do that in Swift, however you can do it by creating a bridging header for Swift. So you'd need to add a bridging-header.h to the project, then set the compile target up to use the bridging header, and finally add this to the bridging header: #include <CoreFoundation/CoreFoundation.h> #if __cplusplus extern "C" { #endif CFPropertyListRef MGCopyAnswer(CFStringRef property); #if __cplusplus } #endif
- xenadu02 11y agoThat's not correct. You can define it with @asmname.
- terhechte 11y agoThanks, I didn't know about that. I've since written a blog post to explain how to do it in Swift (also because I wanted to try it out) here (http://appventure.me/2015/09/30/getting-iphone6s-foundry-from-swift/ http://appventure.me/2015/09/30/getting-iphone6s-foundry-fro...) I've included your helpful info. Thanks!
- listic 11y agoI hope this code finds way into mainstream system information apps on App Store.
- rsync 11y agoPlease pardon my ignorance... My impression was that only apple approved, app-store delivered software could run on iPhone/iPad/iWhatever ... Am I wrong to be surprised to see an "iOS utility" hosted on github ? What am I missing here ?
- adysan 11y agoAnyone can build it and put it on their device, all you need is Xcode and a Mac in addition to your iOS device.
- glhaynes 11y agoiOS apps can be built/signed/installed from a Mac running Xcode 7 without any extra requirements. I'm surprised this fact hasn't gotten more press.
- phaker 11y agoNow this is interesting, had to dig it out: Free On-Device Development Now everyone can run and test their own app on a device—for free. You can run and debug your own creations on a Mac, iPhone, iPad, iPod touch, or Apple Watch without any fees, and no programs to join. All you need to do is enter your free Apple ID into Xcode. You can even use the same Apple ID you already use for the App Store or iTunes. Once you’ve perfected your app the Apple Developer Program can help you get it on the App Store. See Launching Your App on Devices for detailed information about installing and running on devices. ( From the feature list for xcode 7 — https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_7_0.html https://developer.apple.com/library/prerelease/ios/documenta... ) My theory was that the whole developer key thing was a very effective piracy countermeasure — registering and paying $100/year (iirc) is expensive and inconvenient enough that it's easier to just buy things. What has changed?
- gareim 11y agoI believe that you still have to build it to install it on your iPhone, so the likelihood of this being used for piracy is low. Not many commercial apps will have their source code available publicly.
- marcosscriven 11y agoHow did he know what manufacturers those ids mapped to? https://github.com/WDUK/A9ChipSource/blob/master/A9ChipSource/ViewController.m#L52 https://github.com/WDUK/A9ChipSource/blob/master/A9ChipSourc...
- marcosscriven 11y agohttps://github.com/WDUK/A9ChipSource/commit/118eb9538d90242268daf39239322db7757ae484#commitcomment-13527104 https://github.com/WDUK/A9ChipSource/commit/118eb9538d902422...
- WDUK 11y agoHi guys, I'm the creator of this little utility. Just noticed a flood of Stars on the repo, and thought it might be posted here. Information on the chip identifiers was derived from the original closed source tool, and theiphonewiki (https://www.theiphonewiki.com/wiki/S8003 https://www.theiphonewiki.com/wiki/S8003 and https://www.theiphonewiki.com/wiki/S8000 https://www.theiphonewiki.com/wiki/S8000). Motivation was basically to have an open source version of the tool, which didn't relay information back to a server or use advertising. Plus having people install unauthorised apps using a leaked/dodgy enterprise distribution certificate is a dangerous game; having an open source tool allows people in the know to install it on their own devices, safe in the knowledge what it's going to do.