Enter Sandbox part 24: Intercepting Buffers #3 – The Punto H & magic points

Posted on by

I mentioned that monitoring buffers is the key to quickly understand the software inner workings. It doesn’t work all the time, but in majority of cases it does. More so, in ‘desperately’ challenging cases it may help to gain access to the internals of a highly obfuscated code, sometimes even virtualized, and may help to understand large, bulky programs that are really hard to analyze using ‘static’ tools.

Now, we are so used to primarily monitor APIs, and the buffers that these APIs handle, that we often forget that there are many additional places where the monitoring could take place.

I listed a lot of examples in the past. And there are always more ideas. Think of it – your sandbox is your baby. You know every single bit of it. You control its existence. You can extract hard-coded addresses for certain functions, or patch some code. You can modify the OS any way you want. You can even replace every OS single file, disable OS anti-tampering code, introduce clever redirections, callbacks – sky is the limit really. It is a controlled environment. Let’s be adventurous with that.

And yes, this is hard, and perhaps sounds like a very abstract idea, but these are many of available possibilities that may actually work well, if applied to modern sandboxes leveraging techniques that typically focus on inspecting the guest system from the outside (as opposed to old API monitors).

You may ask – it all sounds nice, why don’t I provide some more specific example? I am glad you asked. This is the topic of this post.

I personally find the Punto.H / Point.H trick to be one of the best examples of such cleverly placed breakpoints. The trick was developed by a community mainly focused on an art of software cracking and…. very looooooong time ago (the trick is often attributed to Ricardo Narvaja). And yes, it sounds archaic, and it really is.

How does it work?

The old shareware applications usually asked for a serial key. Most of them, especially in the early days, would just ask for a string provided by the user. Once entered, the serial would be retrieved from the UI control (edit box), and would be tested with the program’s serial verification routine. If the serial was OK, program would be reconfigured as ‘registered’.

Shareware programs were very popular back then, but many of them were quite bulky, plus there was no decompilers yet, and it was quite a pain to analyze them. The observant reversers noticed that by intercepting the calls to the internal function called ‘hmemcpy’ they could see all the data being sent between the program UI and its internals. The first letter of the function gave the name to the actual technique: ‘Punto.H’ (since it was very popular among Spanish-speaking crackers, I opted to use the Spanish name in this article, instead of English ‘Point.H’).

So, catching these buffers pretty much was the first step to crack serials. Once you got the buffer, you could track it and eventually reach the actual routine that was processing it. And then, either patch the code to bypass the serial check, or more advanced reversers would write a serial generator, one that would generate strings that the program would accept. It sounds pretty simple, but typically required many hours of work. The Punto.h trick simplified the cracking process a lot.

Again, it’s really different now with regards to software protection, but this technique still illustrates the point: you need to look for good places where you can add breakpoints for monitoring. Punto.h was so popular that even today there are still many plug-ins that implement this technique and its clones, often introducing many other and additional breakpoints for other software platforms, for example:

Blue Sheet Of Cyber v0.2

Posted on by

I have updated the sheet based on a feedback I got so far.

One of the ideas that drove the development of this sheet was this question: who is a better hire: a forensicator with 15 years of bit-by-bit/primarily encase experience on the LE job, or talented young engineer who loves breaking stuff apart and already made a dent on the industry by discovering new forensic artifacts, writing tools, and presenting novelty ideas at conferences?

This is the reality of cyber (not only blue teams) for last 20+ years, and in my view it is one of the reason why we see everyone talking about ‘talent shortage’. This is because they look at the numbers, and characteristics of people already employed in the space. Not these that could be.

As such, the ‘talent shortage’ may not be an accurate statement if we change the scene. I’d argue that unlike other industries where primarily experience and academically obtained skills matter, the ‘canonical knowledge’, ‘adaptability’ and obviously the actual experience & academic achievements all play important role in diagnosing that ‘shortage’ and for individuals – their ‘hireability’.

And to add insult to the injury, given the fact that most blue team junior analysts are assumed to be almost clueless at first, the ‘jack of all trades’ approach dictates that with a proper mentorship, they can quickly conquer shallow waters of the knowledge necessary to progress to the next higher technical level. The path will quickly become more demanding then, but by the time they get to the next level, it may as well happen they will be already very well prepared. A.K.A. hiring juniors w/o experience should be done with doors open by default, and only closed if candidate makes it happen. Part of me doesn’t believe what I wrote, because I had mixed experience interviewing people for very junior positions, but maybe at that time I was still too biased(?).

The second reason that drove the development of this sheet was this: it tries to support manager’s work; junior analysts often want to know what is that they should learn to ‘climb’. Even if some engineer doesn’t particularly see a need for the ‘advancement’ of their career, and may see such matrix as counter-productive, even anti-climatic and bringing bad blood to the team, they will hopefully appreciate that an ability to self-asses themselves is a nice thing to have. Again, not important today, but may become important tomorrow. Like any other industry before, things will most likely slow down, stagnate, salaries will get adjusted, market saturated with new talent, competition will be harder, etc. etc. – luck favors prepared mind as they say.

And in terms of how to interpret the sheet. I guess we should see the ‘right wing’ on the sheet as a cumulative effort of many years of experience, and a result of many technical ‘lives’ of an individual coming together. The ‘left wing’ is the Jack of Few Trades, the ‘right wing’ is the Jack of Many. I would argue that working for various companies over the years (whether as an FTE, or a consultant) puts people with such a wide experience in a more favorable position here. This is indirectly supported by the process of promotions happening typically when people change the jobs, not on the jobs.

Last, but not least – the stuff that is already in there shows that the era of introvert nerds that just want, and are allowed to do ‘technical’ stuff only is no longer…

The file can be downloaded from here.