Pretty much how I started cracking game copy protections in the late 80's/early 90's. I already owned the games I was cracking, it just became more interesting to me how these protections were implemented and how I'd defeat them. Sometimes I think that was more fun than the game itself. I just didn't want to have to look up pages in manuals or read maroon colored paper with dark blue ink.
I didn't have the luxury of Ida Pro back then, but I did find a disassembler. Using that I'd read through the game code until I found the conditional jumps and then patched the original file with 0xE8 (JEZ?), 0xEB (JMP?), or 0xCD 0x90 (NOP?). At one time I used to be able to recognize just the Opcodes in hex, so I might have those wrong today.
When I started working at Egghead, I was granted time by my manger to crack games for our demo station, so we wouldn't have to jump through hoops on the sales floor. For various professional reasons I've had the pleasure of bypassing my company's own protections. Most recently I used Smali/Baksmali to demonstrate how our company's Android beta timebomb was pretty easy to circumvent.
Once a hacker, always a hacker. I have no doubt that this low level tinkering was why I got into computers in the first place and why they still hold my fascination.
Patching an APK like this would break parts of the app, specifically the parts that are arguably the most crucial to be followed by pinned API calls. For example, in-app purchases via Google Play that validate the app's signing would all fail. Similarly restoring any previous in app purchases would also fail. Finally, you wouldn't be able to install this APK without uninstalling the valid production APK first, again due to signature/signing mismatch.
Cydia performs dynamic hooking, and patches the function in the runtime. In theory app's signature should be intact (I have never come across this scenario in practice, so might be wrong). Generally, application implement additional checks for function hooking and dynamic library injections to prevent such attacks.
Very cool workaround in the article, but it feels like it's just another hole that is going to be closed off. It's impossible to balance because on the one hand we want these fortresses to protect us from prying eyes (see apple vs fbi), but manufacturers are also using these fortresses to keep out owners who just want to hack on their own things.
I'm glad Apple is working to keep backdoors out of iOS, but I still prefer Android because I can get into it anyway I want, and do things like the OP without having to resort to backdooring my own device.
> It's impossible to balance because on the one hand we want these fortresses to protect us from prying eyes (see apple vs fbi), but manufacturers are also using these fortresses to keep out owners who just want to hack on their own things.
I think it's very easy to balance: it's my fortress, because I bought it; I should therefor be allowed and enabled to make it do anything I like. The recent changes which Google have announced — which mean that apps will no longer respect the keys I have installed on my devices — are a move in exactly the wrong direction.
Y'know, I honestly don't care all that much if normal people can screw up: learning not to screw up should be part of the public school education all our taxes pay for. We trust normal people not to stab themselves in the eye, not to shoot themselves through the head, not to crash their cars into others: we should trust them not to do stupid stuff on their computing devices.
And when they do, we should hold them liable for any damage their actions have caused to others, just as we do with all those other tools. Yes, I think liability for allowing one's computer to become part of a botnet is a Good Idea™. Car crashes aren't accidents, and allowing one's computer to become infected isn't accidental either.
That's what I'm arguing for. In this country the public pays for 12-13 years of education and subsidises another four; I'm arguing that among the subjects we should cover with that massive investment is 'don't be an idiot with computers,' much as we have drivers' ed.
> but manufacturers are also using these fortresses to keep out owners who just want to hack on their own things.
I'll play the devils advocate:
1. From manufacturers perspective, it is very difficult to differentiate if the modification are being intentionally done by the owner of the device, or if the owner is being attacked by a 3rd party (e.g. via malware or JTAG)
2. Ownership ends with the device and the app - you cannot 'own' a service that Google/Niantic/Apple/Steam are providing. They can dictate the terms for providing that service and for an online game like Pokemon, not having access to the service makes the ownership the app and the device pointless.
I think 98% of people are really better off in a closed system (excluding piracy). The real issue IMO is getting developer access to any Android or iOS device should be a straightforward and free process.
They're not better off - that's a bit like saying people would be better off if hairdryers were DRMed by magic to heat up only hair. Those closed systems are significantly limiting the usefulness of computing devices. Hell, it's getting hard to call modern mobile platforms "computing devices" - they're becoming glorified TV screens / pretty interfaces to your credit card.
Also, that remaining 2% has to come from somewhere. People learn to make next-gen tech by playing with and reverse-engineering today's tech.
Considering how many people download and install software that harms their PC, where tablets and phones are 'safe' it's complicated. People just don't ask others to come and fix my tablet which really is a vast improvement.
This seems like overly complicated. He could have made the public key extremely small by just placing 0x00s in it so that he could crack it. Easy patching.
Xposed module patching only works when SSLPinning is performed in the Java code of the application, as Xposed provides a mechanism for intercepting Java method calls only. Unlike in this case, the code is in C/C++ layer, hence can't be used.
I believe you, so please don't take this is a challenge. It's pure curiosity that prompts me to ask: Do you have a source for more info on this IP range ban?
What's the added value of using imgur's embed code rather than a good ol' <img>? Is this a trend? I would understand it for albums, but why would you do it for individual images? </rant>
"Also, don't use Imgur to host image libraries you link to from elsewhere, content for your website, advertising, avatars, or anything else that turns us into your content delivery network."
Seems as though they don't want to be a CDN, not that they don't want direct linking from forum users? Anyway I went for a dig through Alan's old reddit posts because I thought I recalled him saying he's fine with direct links
> Nothing has changed in regards to direct linking. I'm not sure what you're seeing exactly, but we'll always allow you to direct link to any image you want.
> People linking to the page rather than the image is what keeps imgur going. If everyone linked to the direct image then imgur would have no source of revenue. However, I want people to use the service however they want, and by no means would I ever force anyone to do it one certain way. So, I like it when people link to the page because that's how imgur makes money, but you don't have to do it if you don't want to. I'm just happy that you like the service.
> Also, don't use Imgur to host image libraries you link to from elsewhere,
what can that possibly mean? there's no way to use imgur at all without linking to it from elsewhere, except if you visit imgur.com as a destination site (which is fine, but not how imgur has been promoting itself for years)
The people who most want hotlink-embedding are precisely the people who don't "own" a website, but rather are posting content on someone else's services (forums, blog hosts, etc.) that allow semi-arbitrary HTML embedding (so you can write an <img> tag) but don't support attachment uploading or auto-rehosting.
Hey guys, author here. I used the embed code because some of the images are large and WordPress wasn't resizing them correctly for some reason. I also was unaware of the policy in Imgur's ToS. I will look into these issues and update the article accordingly.
Well it might or might not be against the ToS. I personally just think it's bad practice to use resources you don't have to.
People just want to share a funny picture and that's okay. But if you already own web space somewhere, use it and pay those extra few cents (if anything) to host your own images.
> What's the added value of using imgur's embed code rather than a good ol' <img>?
Well, you can shaft users who browse without JavaScript turned on and help destroy the Web, all in one fell swoop!
I particularly hate how imgur requires JavaScript to use. We have had images in HTML for over twenty years now, and for some reason imgur has decided that they are above all that.
They could easily write a <noscript> section but probably don't to reduce bandwidth. Anyway they use React pretty heavily which is why they "need" JS support
As mentioned in the comments, this doesn't work when you try to sign in via Google because it checks the signature of the app. The PTC signon doesn't do this so it's currently allowed, but I'm sure Niantic will patch it soon.
![http://imgur.com/foo.jpg"](http://imgur.com/foo.jpg"){kind=link}
I didn't have the luxury of Ida Pro back then, but I did find a disassembler. Using that I'd read through the game code until I found the conditional jumps and then patched the original file with 0xE8 (JEZ?), 0xEB (JMP?), or 0xCD 0x90 (NOP?). At one time I used to be able to recognize just the Opcodes in hex, so I might have those wrong today.
When I started working at Egghead, I was granted time by my manger to crack games for our demo station, so we wouldn't have to jump through hoops on the sales floor. For various professional reasons I've had the pleasure of bypassing my company's own protections. Most recently I used Smali/Baksmali to demonstrate how our company's Android beta timebomb was pretty easy to circumvent.
Once a hacker, always a hacker. I have no doubt that this low level tinkering was why I got into computers in the first place and why they still hold my fascination.