3eed

7 ms·

1.
by 3eed 2y ago
This is incredibly helpful, kudos to everyone who worked on this.
2.
Calling Swift functions from JavaScript using Frida(twitter.com)
3 points by 3eed 5y ago|0 comments
3.
Standardizing Automated Security Testing for IoT: Bluetooth LE(nowsecure.com)
1 points by 3eed 5y ago|0 comments
4.
Reverse Engineering iMessage: Leveraging the Hardware to Protect the Software(nowsecure.com)
3 points by 3eed 6y ago|0 comments
5.
Xpcspy: XPC message interception, serialization and filtering(github.com)
1 points by 3eed 6y ago|0 comments
6.
Reverse Engineering Starling Bank (Part II): Jailbreak Detection and Mitigations(hot3eed.github.io)
1 points by 3eed 6y ago|0 comments
7.
Reverse Engineering Starling Bank (Part I): Obfuscation Techniques(hot3eed.github.io)
2 points by 3eed 6y ago|0 comments
8.
by 3eed 6y ago
I came across Arybo while working on the binary but I can't remember why I didn't use it, this is vague memory now. Anyway it does the job in one go, I added an edit.
9.
by 3eed 6y ago
That guy gets it
10.
by 3eed 6y ago
It does check for a debugger. But that would be through sysctl, or the csops sys call, which would be trivial to patch and a single point of failure.
11.
by 3eed 6y ago
Are hardware breakpoints even possible on iOS? And correct, you can't patch the binary because there many anti-tampering measures, you could probably bypass those, but that's going a different route.
12.
by 3eed 6y ago
DeviceCheck on iOS support iOS 11 and up. Which would cut off 7% of users[1], a bit extreme. But when the time comes when you don't have to cut off anyone, it'll be very interesting to see what'll happen on iOS. Someone will
13.
by 3eed 6y ago
It's true, these posts are for intermediate and upper reverse engineers. It would really take a book to explain it from the ground up it like someone here mentioned. I suggest getting some background in assembly, then reading the OWASP
14.
Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable(hot3eed.github.io)
295 points by 3eed 6y ago|61 comments
15.
by 3eed 6y ago
https://news.ycombinator.com/item?id=23563556
16.
by 3eed 6y ago
Security is a continuum, how much resource you can put into fending off prying eyes depends on how valuable your assets are and so how many prying eyes are targeting you. But as a start OLLVM is open source and not bad at all.
17.
by 3eed 6y ago
Why not ;)
18.
by 3eed 6y ago
That'd be a noticeable performance hit I'd say.
19.
by 3eed 6y ago
You could manage to isolate these functions. The problem is that it's much of a hassle to run the whole thing on an emulator because there are way too many real environment dependencies, and even if you go the hackery way and patch all
20.
by 3eed 6y ago
You need some assembly background, then OWASP's guide[1], has all basics. [1]: https://github.com/OWASP/owasp-mstg
21.
by 3eed 6y ago
"Evan Spiegel Hates this Trick!"
22.
by 3eed 6y ago
Couldn't agree more.
23.
by 3eed 6y ago
Hmm, I wonder how deep one should look. Why don't you shoot me an email at hot3eed at gmail? I'd appreciate it a lot!
24.
by 3eed 6y ago
Sure! I'll consider doing this before the next post
25.
by 3eed 6y ago
Definitely not true.
26.
by 3eed 6y ago
Not all of it, really ;)
27.
by 3eed 6y ago
All these are great programs, but none of them can understand that level of obfuscation so far. As stated in the post, both Ghidra and IDA interpret the very first block in any of the obfuscated functions, which ends with an indirect branch
28.
by 3eed 6y ago
I'm gonna write about this in pt. 2. Basically you can use symbolic execution to recover the CFG[1] (using something like miasm), you can eliminate dead code, restore dynamic lib calls with an emulation, and whatever else. But the poin
29.
by 3eed 6y ago
That’s interesting to know
30.
by 3eed 6y ago
The vast majority of these obfuscations (maybe except for the scratch arguments one) are done as LLVM passes, so it's done post-code writing, writing code like this would be unreadable and unmaintainable.

More ›