Hacker Newsnew | past | comments | ask | show | jobs | submit | hackernewsn00b's commentslogin

You should take a beat and search the keywords, "trading capacity constraint."

That will lead you to the reasons why it is very possible to both beat the market and be incapable of scaling it up to billions of dollars.

tl;dr: Someone who has found a way to reliably arbitrage to 25% gains year over year on an inefficiency that will only fill about $100,000 is not going to be able to cash their system in for billions of dollars. But they will be reliably beating the market (on a risk-adjusted basis: assuming the system has risk equal to or less than holding e.g. the S&P).

You will find that firms which can actually reliably beat the market do tend to make their founders wealthy. But they can't scale it beyond the capacity allowed for by the inefficiency. All successful hedge funds and prop shops eventually reach a point where they can't reinvest the returns for the same gain.


Hey OP, since you're here:

I find this pretty hard to follow. Would you be open to writing a longform version of this aimed at the tutorial level?

Reading between the lines, I would guess you're trying to demonstrate that you really know what you're doing. Maybe as a proof of concept for possible employment opportunities. If so, that's great! Good luck.

But if I were interested in reverse engineering some other app, I don't think I could understand what you've done well enough to use these techniques on that app. Except maybe the breakpointing within `fuck_debug`, that was pretty slick and easy to follow.


If reading even the first part of this series doesn't help, read this beginner tutorial I recently wrote: https://yasoob.me/posts/reverse-engineering-android-apps-apk... It starts you off with the basics and uses smali.

After that you can explore this tutorial on frida: https://securitygrind.com/bypassing-android-ssl-pinning-with... These two techniques will give you some more basic knowledge of how app reversing is done. :)


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 guide (link in my previous HN post), and persistence.


Obviously not the OP but I think that a longform version of this would be an entire book/college level course. I wish I could learn how to reverse state of the art obfuscation in a single, long post but that's just not how it works.


I would pay for that book.


I found it fairly reasonable, although you'd have to have a general idea of the subject beforehand. I read it as a being aimed at reverse engineers who are looking for some general techniques to bypass common anti-debugging/obfuscation features rather than "how to reverse engineer apps 101".


"Reasonable" is a stretch, "interesting" is the right word. Personally I'd put this in the "Oh, huh" box along with quantum crypto. It's interesting, it's complex and it's got way too many engineering hours behind it... but ultimately for 99% of people or even 99% of computer scientists or HN readers, it's just fascinating trivia.

I absolutely appreciate these posts, this guy spent WEEKS delving into the depths of SnapChat just for the joy of discovery.

Maybe a good classification would be that part 1 is detailing a number of obfuscation techniques and the key thing to take away is that all of them CAN be bypassed.


It's easier to follow if you read part I of the series first:

https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.ht...


+1. Need a simpler version if possible.


Can you talk a little bit more about why server side logs aren't accurate for analytics? I was planning on doing basic analytics (pageviews mostly) using Cloudfront access logs stored in an S3 bucket and queried through Athena for a site I'm working on which uses the AWS stack.

I know Cloudfront logs can sometimes drop, but is there a more important reason you're talking about?


I think with server-side only is harder to filter bots, crawlers and get accurate bounce rates or session length times.


Shameless plug, you might want to have a look at https://github.com/ownstats/ownstats


> Stanford probably just suffering a little "not invented here" syndrome.

SJCL predates libsodium.js :)


This appears so.

From the SJCL documentation:

> An older version of this implementation is available in the public domain, but this one is (c) Emily Stark, Mike Hamburg, Dan Boneh, Stanford University 2008-2010 and BSD-licensed for liability reasons.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: