HNHacker News
TopNewBestAskShowJobs

yifanlu

701 karma · joined March 26, 2012

[ my public key: https://keybase.io/yifanlu; my proof: https://keybase.io/yifanlu/sigs/AI8h9qa813m7jhRG5dwR8sD69joHRJ-wjioJl0iOERM ]
submissionscomments
yifanlu··on The 3DS Cryptosystem
So we have FIRM, the main firmware image. It has three segments: 1) main ARM11 kernel modules, 2) ARM11 kernel, 3) ARM9 kernel/ARM9 process. The FIRM header has a SHA256 hash over all the segments and the size of all segments. The FIRM header also has a RSA2048 signature over the header. Then everything (sig + header + FIRM) is encrypted with AES-CTR and placed on the NAND.

On system start, the whole chunk is decrypted, the signature is verified, and everything works as expected. Until in the New 3DS, they decide to also additionally encrypt segment 3 (the ARM9 stuff) with a separate key on the NAND. That's what led to the whole mess. So I guess their mistaken assumption was that since FIRM was signed, the encrypted ARM9 section was protected. However, they didn't take account of the fact that the key to decrypt it can be corrupted. It's a bit subtle.

yifanlu··on The 3DS Cryptosystem
First, the 3DS mostly uses RSA for code signing, something I didn't really touch on since there's no serious mistakes there. Second, while RSA does not fair well against quantum attacks, as of today, there is still no way of factoring a 2048 bit key that won't take you at least (being generous) hundreds of years (provided no quantum computers). So if you have proof that it's (today) achievable in polynomial time, please email me ;)

But turning the question around, what do you think we should do to achieve asymmetric encryption? If you don't want it to break with Shor, then RSA and ECDSA are off the table. If you want small message size, you can't use Lamport.

yifanlu··on The 3DS Cryptosystem
As a simplification, I did not draw any of the blocks contributing to code signing. RSA is used everywhere to ensure that the code is signed. If you consider the signature as the MAC, it does "Authenticate Then Encrypt" (the signature is over the NCCH or FIRM header. The header contains hash + size of each section.)
yifanlu··on The 3DS Cryptosystem
Well the first break that brought piracy happened about two years after launch. Also, the Vita, which launched around the same time is sill unhacked pretty much. It's a shame that there's not as much good games on there for it to be a commerical success. In fact the Vita does so many things right that the 3ds fails at (security wise).
yifanlu··on C++11 metaprogramming applied to software obfuscation (2014) [pdf]
How well does it defend against this deobfuscation approach? https://www.cs.arizona.edu/people/debray/Publications/generi...
yifanlu··on “Rootless” feature in El Capitan means DTrace no longer works
I don't get that point. "Normal" users won't (and shouldn't) disable SIP. Those who do need to for security research won't really care that Apple knows they're poking into the system (when you disclose a vulnerability, they'll know who you are) and for the very paranoid, you can disable network or block connections to Apple or etc.

It's a strawman argument because for security researchers, there is never a problem of "we can't let them know we're looking". There's also no evidence that Apple phones home the status either.

And re:"barrier of entry". Who should we be protecting? Amateur security researchers or mass users? As an amateur security researcher I'd happily allow my job to be 10x harder if it makes users even 2x safer.

yifanlu··on “Rootless” feature in El Capitan means DTrace no longer works
Okay, there's many problems with this post.

First, most people do not need to use dtrace. Especially on system processes. They claim that this is bad for security researchers because they can't monitor the system anymore and they showed a screenshot of dtrace not working even with SIP "disabled". However, from the screenshot, we see that SIP is, in fact not disabled because of this line

> System Integrity Protection status: enabled.

You can see here http://internals.exposed/blog/dtrace-vs-sip.html that with SIP properly disabled, you can run dtrace on system processes. Yes, it's confusing that it says "DTrace restrictions: disabled", when it should say "some dtrace restrictions".

Also, no security researcher worth their salt would be stopped by this (and no "bad guy" would be stopped from debugging either). In fact, dtrace is only a convenience and one tool in a toolbox; you have VMs with kernel level debuggers. You have object code analysis. You have wireshark and so on. If Apple can't stop people from jailbreaking their iphones (where hardware enforces the lockdown), they won't stop people from debugging their PC's kernel.

Basically, SIP is good for users (the "Ultimately this means that Apple has replaced the 'be all and end all' security barrier of the root password, with the 'be all and end all' SIP protection mechanism." argument is the same as "we shouldn't outlaw guns because people will find other ways of killing each other") since it makes compromising a system all that harder. If it hinders ANY security research, I question the skills of that researcher.

yifanlu··on TSA Doesn’t Care That Its Luggage Locks Have Been Hacked
The outrage isn't that your luggage can be stolen now. The outrage is that a) the government felt that it needed to invade the privacy of our luggage for security; so they made these master keys (yes, you can pull them apart with your hands, but provided the TSA doesn't regularly go through luggages, a broken lock is a quick way of telling someone's been through your stuff and you can take action appropriately) and b) it's been revealed that these keys can easily be obtained and the government does not care--showing the broader problem of what happens when you compromise privacy for "security".
yifanlu··on Hacking the PS4, part 3: Kernel exploitation
First, there is no "kernel exploits from vulnerable games" as games are applications that run in the OS (FreeBSD based). What happened with the PSP is that game exploits can be used to run code that trigger kernel exploits (which have to be found separately and are a lot harder to find). In terms of game exploits on the PS4; there is no doubt that such vulnerabilities exist, but you're limited to ROP (no JIT in games) in userland.
yifanlu··on Hacking the PS4, part 3: Kernel exploitation
It is possible to create save files. However they will be tied to a specific console/account. And creating them requires a kernel exploit while a vulnerable game only gives you a userland exploit. It won't be the most practical even if you find a vulnerable game.
yifanlu··on PS4 security article follow up
No, because that breaks the signature.
yifanlu··on PS4 security article follow up
Yeah, it's unauthenticated encryption, but think about their threat model. It's not about protecting integrity (the code signing takes care of that), it's about protecting the code from prying eyes (aka DRM). And the tradeoff with speed is likely why they choose CTR. That has bitten them in the ass before with key reuse, but by PS4 they've had about 10 years of experience with the SELF format now. While I doubt the format is completely secure, it's likely easier to find a flaw in FreeBSD9 (which is why CTurt tried to say).
yifanlu··on PS4 security article follow up
He is misquoting myself and/or other people who've talked about the encryption before. Sony has their own format they call SELF (secure ELF?) which works as follows: each ELF segment (not section) has a key/iv generated for it and is encrypted with AES-CTR (previously same keys were used for different segments, making it vulnerable to attacks). The keys are placed into the header and encrypted with AES-CBC. The decryption key for this is the important one, which if we obtain, allows the decryption of any* SELF. (So an mis-implemented encryption has happened before and doesn't mean 'oh the military uses AES, so anything that uses AES is unbreakable')

There's also the signatures which prevent modifying the SELFs even if we got the decryption keys. The ECDSA random-fail was what happened to the PS3. This has nothing to do with the encryption though. (There was also no "constant 4" that was just a simplification in the slide deck of the presenters. It was meant as a joke.)

But I do understand all the gross simplification CTurt made because the audience for this article is people who watch the console hacking scene, and in the console hacking scene, almost nobody knows anything about crypto. I frequently have to answer why brute forcing 128-bit AES keys is not possible. Then, inevitably, the asker will declare why we don't just try to guess then. Once I was informed that computers will become faster, so, in the future, we can brute force keys "at the speed of light." I asked them how many meters per second we can crack keys now.

* Okay, technically not any. I haven't gone into NPDRM, which is an additional layer of encryption for purchased games. Different keys are also used for different components (for example, kernel vs. user libraries).

yifanlu··on Developer claims 'PS4 officially jailbroken'
This uses an known (and patched) FreeBSD vulnerability (BadIRet). It only works on PS4 <= 1.76 (pretty old now) and is not publicly available (CTurt does not have permission to release it). I think this whole article is just an advertisement for this "green Monday" sale tacked in on the last paragraph.
yifanlu··on Amazon bars the sale of Apple and Google TV devices
I'm not making a judgment either way but you understand that Apple and Google chooses to only sell their things and Amazon choses to sell everything excluding these devices?
yifanlu··on ARM immediate value encoding
https://research.cs.wisc.edu/vertical/papers/2013/isa-power-...

Generally, the thought is that ISA doesn't really affect performance.

yifanlu··on FCC slaps Lyft with citation for calling and texting customers
And why should they last for more than a week if they break rules? Sure, you can argue that the rules are pointless but it would be arrogant for you and I to decide which rules we want to follow and which ones we can ignore. Maybe treating drivers as employees and vetting them would cost more but benefit both parties more. Maybe not. But not doing either definitely benefits the company. And maybe certain rules exist to protect us from companies; even if we don't know it because we haven't lived without such protection.
yifanlu··on A tweetable Turing machine
While a nice novelty, simulating TM on your computer is not that interesting. I mean you can do it with a single instruction: https://en.wikipedia.org/wiki/One_instruction_set_computer (or even zero instructions on x86).
yifanlu··on Hacking the PS Vita
Even if you had a devkit, you still won't know. The devkit is just as sandboxed and there's an additional processor whose sole job is to enforce security on the debugger and PC communications.
yifanlu··on Hacking the PS Vita
Well if I can be pedantic for a second, "valid signing certificate" is much harder to find than any software exploit. In fact if you can find it without physically stealing the certificate, you just broke modern cryptography. And on the vita, if you can sign code, I can load it for you over wifi by faking an update package ;)
yifanlu··on Hacking the PS Vita
Well I don't consider them embedded, but I would say yes for the PS4. I haven't looked at the xbone yet so I can't say anything for that. PS4 uses FreeBSD9 as its kernel. Plus there is no KASLR. In theory, if you find an exploit in freebsd, you can exploit the ps4. Some people already got some kernel memory leaks to work. Meanwhile, the vita uses a custom os built from the PSP but is vaguely similar to it (I wouldn't be surprise if it was a complete rewrite).
yifanlu··on Hacking the PS Vita
How detailed do you want me to get? I've hacked both of them so I can give you as much info as you want. From a broad perspective, Vita has KASLR/ASLR, stack canaries, trustzone, just to name a few standard things that 3ds doesn't have. Overall the 3ds is pretty much "hacked" (only a couple of components are still secured including bootrom and aes engine). Vita is not even hacked at a kernel level yet.
yifanlu··on Hacking the PS Vita
No, typically Sony is hostile towards hackers. Being ignored is the best response from them. I think after the bad press for PS3 and psn hacks, Sony hired security consultants to secure the Vita. They did so many things right that frankly it's suprising. Not everything rolled over into the ps4 though so the vita is more secure than the ps4.
yifanlu··on Hacking the PS Vita
I hope so. But the cynic in me thinks think there won't be as much work because now most people who would work on homebrew games and emulators are now coding for smartphones and tablets. However, by getting an open sdk started and releasing a public exploit for developers (honestly it's not user friendly enough for everyone), I'm hoping the scene will finally get a jump start.
yifanlu··on Hacking the PS Vita
Hello, didn't expect to see this here. I'll be happy to answer any question as I refrained from giving deep technical details in the article. I'm surprised at how secure the Vita is given Sony's track record. I would say that the Vita is the most secure consumer embedded device that's out today.
yifanlu··on Show HN: The remaining unregistered one-word .com domains
Can't believe teargassing.com isn't taken yet.
yifanlu··on Mmap(): Now you're coding with portals
Does this play nice with caches? I know some systems like ARM allow aliases in the MMU which will ensure cache coherency, but it is system dependent and a lazy implementation would just disable caching and slow down the code.
yifanlu··on GameBoy Advance Emulator coming to iOS 7. No Jailbreak required
Yes jailbreak required.

From site: How can I install GBA4iOS? Unlike other apps for iOS, you can not install GBA4iOS from the App Store. Until GBA4iOS 2.0 is released, you can download version 1.6 from iEmulators, run by Start3rs, an awesome group of people who are beta testing GBA4iOS 2.0. To install, open the link on your iOS device, and follow the instructions at the top of the page.

yifanlu··on Proof P!=NP (as one-way functions exist)?
I'm skimming the "simplified" version so forgive me if I'm misinterpreting this.

> However, if we could obtain the inverse function in a feasible way ...

> The answer would be very simple: First, we start executing y on the program M until 5 minutes and ...

> But, this is impossible: we could not reduce the time of 10 centuries to 40 minutes over L due to L is EXP-complete

I have VERY minimal knowledge of this, but does this proof go into why this method to "obtain the inverse function in a feasible way" is the ONLY way or that it encompasses EVERY way to do it?

yifanlu··on This Malware Is Frighteningly Sophisticated And We Don't Know Who Created It
Personally, I only think a malware is sophisticated based on how it infects (like stuxnet with 4 windows zero-days, and windows update hijacking with fake code signing certificate). Spear phishing seems to be pretty boring. I think Kaspersky is just embarrassed that the malware (they say unsuccessfully) originally exploited Kaspersky AV. Also, anyone can write "complicated" C&C software. There's a lot of bundles you can find online that does most of what's listed.
← PreviousPage 3 of 4Next →