There has been a lot of fervor over BitForex’s recent addition of Path Network tokens to its trading platform. With this post we will attempt to address the myriad of questions and hopefully quell some of the frustration.

But first the basics. The Path token is a utility token. It is used to establish credits on the Path platform to pay for services. The hourly cost of those services dictates the value of the credits. It is like an old-style video game arcade token. You insert your quarters into the token machine and receive brass tokens in exchange. You can then take those tokens to any game and insert the token and received the allotted play time.

Path Network entered into purchase agreements with 10 different parties. All parties underwent AML/KYC checks. The token purchasers were made aware of the use of the Path token and that its only value was toward services on the Path Platform. All 10 parties signed token Purchase Agreements and were provided with details about the company and the intended use of the moneys received from the token sales. Each party bought the tokens ostensibly to use them on the Path Platform to further support their own businesses and websites.

If you did not purchase tokens directly from Path Network and do not have a signed contract with Path Network, any issues you have regarding the tokens value and use must be addressed toward the person/company/syndicate from whom you made your purchase.

Though Path is a utility token, the U.S. SEC currently considers ALL tokens sold during an ICO as “securities” and as such has very specific rules. Path has worked to be compliant with these rules and regulations. It is why all Non-US based purchasers had to wait 90 days before being able to transfer their tokens to any other party other than Path Network. U.S. based token purchasers are required to hold the tokens for 366 days and face stiff penalties if they transfer their tokens early.

The SEC also regulates where tokens can be offered for sale. Path Network is prohibited from listing Path tokens on exchanges that are not SEC regulated. The process to get on an SEC regulated exchange is long and costly but Path is working diligently on this front.

If these rules change we will be quick to implement the changes.

Regarding BitForex and Bilaxy-

· Path Network did NOT participate in the listing of Path tokens on either exchange.

· Any token holder can arrange to list a token on an exchange. Listing does not have to be done by the corporate entity behind the tokens

· BitForex’s parent company is a token purchaser. It was their decision to list Path on the exchange. The listing was done legally after the 90-day hold period expired.

· Marshal Webb is a security advisor to BitForex but that relationship is separate from any token purchases. Mr. Webb like many of the Path Network team, Mr. Webb is considered a cyber security expert and his skills are sought be various companies. Path Network has begun work on a consulting arm under the ECKCyber title to assist clients when requested.

· Path Network LLC no longer controls the Path International telegram channel. The “creator” account is held by a former employee of Path Network and we are currently taking legal steps to regain control of that account. At this time Path Network CANNOT remove admins from the International Path channel also the “creator” account has the ability to over ride the actions of Path Network employed moderators.

· Therefore, before believing any postings on the Path International Channel, one should check the Path.net blog or contact Path Network at contact@path.net

Regarding the flood of Path tokens on BitForex-

· The flood was caused by an advisor to Path who was unhappy with Path’s decision not to hire him for “market making.” In response this person decided to sell some of his tokens at a loss in order to harm Path. This person is an American and his transfer of Path tokens took place before the 366 day hold period expired. As such he is liable for SEC legal action. Path is working on the reporting mechanism to address this matter.

· Path Network will never take part in “market making” for our tokens because it is illegal. Buying and selling a token to inflate/manipulate the price is fraud and is punishable by jail time in multiple countries including the U.S. and China.

Regarding the AirDrop-

· The Airdrop was cancelled because 95% of those who signed up failed the AML/KYC checks.

Other facts about Path tokens and the ICO-

· The public sale portion of the ICO was cancelled due to numerous false claims and various other issues resulting from advisors and their connections to syndicates

· Save for the reserve and tokens allocated to employees and advisors, all other unsold tokens have been destroyed.

· Each Path token has a trade-in credit value of $0.40 toward Path Services to include all network traffic monitoring, DDoS mitigation, near bullet-proof VPN and others. If a token holder does not want to use a Path offered service, there are clients who might be interested in acquiring your tokens

· The $0.40 credit value is based on the current hourly cost to perform the services. This value will increase as the operating costs decrease.

· Operators whose nodes have been used to conduct jobs for Path clients will be paid in tokens beginning in early Dec. 2018.

· Path currently has an Android based app and is set to release an iOS version in coming weeks

We hope this post answers most of the questions you have regarding Path Network and our tokens. And know this, there are amazing things happening at Path Network that will be truly disruptive to the Network Traffic Monitoring and Network Visualization arena. Check out www.Path.net to learn more.

Previously, we dove into how Path Network functions and touched a little bit on our mobile app. With our mobile app now running in the wild, we'd like to cover its capabilities and how they benefit those running the app and monitoring clients alike.

What is the Path Mobile app?

For those not in the know, the Path Mobile app allows anyone with a mobile phone to effortlessly earn PATH tokens throughout the day. Tokens are earned by completing non-resource-intensive networking tasks as the app runs discretely in the background.The Path Mobile app for Android was recently released to the public via Google Play, so if you haven't already, you can check it out here!

So, how do I use it?

Usage of the app itself is so simple, it can be boiled down to three steps:

Install and open the app.

On the wallet tab, enter and save a valid ERC-20 wallet address to receive earned tokens. If you don't have a wallet address, we recommend using MyEtherWallet.com to generate one.

Leave the app running to begin processing jobs on the Path Network!

Adding your wallet to the Path Mobile app.

Behind the scenes

The technology is advanced, but the concept is simple: individual nodes within the network will be assigned monitoring tasks (eg, checking to make sure a website is up and running). In exchange for these tasks, they will be rewarded with PATH tokens.But what goes on behind the scenes? Our telemetry is really what makes Path Network shine, so let's take a peek at what's going on.When a node is started, it will check in with our Operator API via a WebSocket connection to let us know it's online and ready to receive tasks. These simple check-ins alone already give us some insight into the health of an ISP; more specifically, where IPs are being assigned within an ASN, and whether connections to our servers are being routed properly.Once the monitoring jobs start coming in, things can start to really get interesting. While the most common tasks performed are simple pings and HTTP queries, Path nodes are capable of so much more. For example, TCP and UDP connections may be defined with custom payloads within a monitoring task, allowing flexibility previously unseen. DNS queries and traceroutes may be performed to map out exactly where network connections are going.

Regardless of the monitoring task performed, all information will be transmitted back to Path's servers for analysis. Everything from the timestamp of a connection being opened to the very last bit of response data received will be processed to verify an endpoint is available and functioning as expected.

What does running monitoring jobs on mobile nodes mean for a client?

Based on the jobs given, we can answer a variety of questions about a given service.For example, a basic DNS query can answer:Which DNS server was queried?What records came back?How fast was the resolution?Were the records what we expected them to be? If not, has the DNS server been compromised?

A traceroute will determine:What route did the connection take?How many hops?How long did it take to establish the initial connection?Was there a better route that could have been taken?Is it possible a BGP hijack has occured?

HTTP queries can tell us:Is the website content loading as it should?How long did it take for everything to finish loading on the page?How much data was loaded?Did we get back the response we expected?

All of these are critical questions, and some may be answered through alternative monitoring services; however, our globally distributed network puts is in a unique position to answer one big question that others simply cannot:Is this issue affecting everyone or is it limited to a specific location or ISP?

In the first article, DevBlog 0x01 we covered a high level overview of our technology. In this article, we will continue with a deeper dive down into how Path Network works.

So, what is so unique about PATH Network?

Path Network is a distributed network monitoring company, based on the blockchain. Using our unique new global Path network, we help companies understand how their network operates, with detailed insights and statistics right down to specific networks and physical locations.

We hear all the time about net neutrality and how it is going to impact services, but nobody is out there measuring it... Path Network can see when it's throttled, when it's deprioritised, and when it's given bad routes - and we can detect that all in real-time! So, all of this is pretty new and exciting technology...

Traditional network monitoring services operate out of a small selection of ISPs and CSPs. They run out of the limited number of regions in AWS, Azure, GCP for example, and they also can run out of physical datacenter locations - probably the same old datacentres that everyone else is operating from... this is quite limited.

This means that companies are not getting the visibility of how or even IF a customer is reaching their network, and using their service, on a global scale...

As a very simple example: You are running an eCommerce website, (ie. an online shopping store based out of California), and you have customers all over the world.Suddenly, you have an influx of complaints coming through your technical support channel that customers are having a very slow user experience.... But the site looks good to you ... ? More support complaints come in, and someone finally realizes that they all seem to be in Texas. But who and why?

Path Network can tell you that it's not actually all users in Texas, but it's specific users in Texas who are connect to the internet through Comcast.

With our global distributed network, and a combination of both commercial and residential monitoring nodes, we're able to pinpoint causes of such issues, down to the exact network ... and even an exact physical location.

Path Network Live Demonstration

In this video, we'll perform a live demonstration of our production panel platform, showcasing how it can be used by customers and the power of our technology.

Why Crypto?

Well, for a few reasons!

Firstly, being able to harness the last mile between Companies and Customers, and being able to see exactly what a Customer sees, is exactly why Path Network is so powerful.

We are able to provide visibility by harnessing the power of consumer electronic devices such as phones, laptops and the excess bandwidth that is not used by the device - for example, when your phone is on standby.

Instead of sucking up your battery life, your phone could be making you some money!

The best part? It also contributes to making the internet a safer place.

By launching our own ERC-20 Token, PATH, the power of cryptocurrency and all of the benefits it provides was a no-brainer ... It is a global, 24/7, secure, non-cash, payment system - not a local currency. This allows instant payment for accessing PATH Network services and also allows us to pay mobile PATH node operators, anywhere in the world ... at any time.

Quite simply, it is the easiest way to earn micro-payments so you can make some money and offset your phone bill!

Blockchain is important to PATH Network because, not only does it encourage users to run a PATH node on their phone for payment in crypto, it also allows us to provide our advanced monitoring and network security capabilities.

Future of Path Network

With our mobile application launch imminent, now is probably a great time to talk about the future of Path Network! Today, everything you see is actually in the past as we at Path Network are now focused on the future. We are very proud of our achievements, and are focused on accomplishing even greater things in the foreseeable future. 2018 has been wild, but 2019 is going to be extreme!

Once the network is up and running at full strength we will be rolling out many new and exciting features, to fully harness the power of our network intelligence. It will be an extremely exciting new year.

With our mobile application now releasing on Android within the Google Play Store, we have already started development on Version 2 - which will have more job types, a very modern UI that was showcased in DevBlog Episode 1, an iPhone version, code libraries for further implementation and a few key partnerships.

The First Path Datacentre

We have even started the rollout of our physical infrastructure!

Whilst we strongly leverage Cloud technology, there are some things that only physical Points-of-Presence, globally, will be able to provide us. Important features, such as BGP feeds, advanced network monitoring, and security services, will now all be possible for co-location providers.

We have purchased AS396998, as well as a large IP space and we are now in the middle of an even bigger infrastructure roll out than what we currently have in AWS.

So as we accelerate towards the end of this year, we hope you will jump on in with us, and enjoy the ride!

Hi, my name is Matthew Flannery, and welcome to the first post in our DevBlog series!

I made a short video about this blog post, and we're planning on making a few more! I hope you enjoy this.

During this series of posts, we'll dive deep into our latest technology updates and provide insight into why certain technical and architectural decisions were made, share our learnings with you and most importantly, share our progress. We'll try to keep things entertaining, including doing some written interviews with key members of our Development team, and perhaps some podcasts.

This first article provides an overview of the Path Network platform. We won't be focusing too much on describing what Path Network is, as that is expertly written within our whitepaper, available on https://path.network

Platform Overview

The premise of the platform behind Path Network is simple: Allow as near to real-time data processing as technically possible. Accept connections to millions of Path Nodes concurrently at any time, and maintain connections to those Nodes for the purpose of distributing Jobs, and receiving Job Results.

As you can see, our technology stack is diverse and pretty awesome to work with. Because we are dealing with millions of concurrent connections to Path Nodes at any time, distributed systems engineering and microservices architecture are paramount.

The panel frontend is a ReactJS SPA (Single Page Application) which invokes various backend RESTful/GraphQL serverless APIs (Kafka producers), which push jobs into a Kafka topic. These messages are processed into a Kafka Streams state store. This allows continuous query, read, write and processing of data into Kafka in real-time and at scale, and consumed by an API which provides jobs to the clients (Path Nodes).

Kafka is architected in a way that is highly available, fault tolerant, and autoscaling to meet intensive demand as the platform user base grows. This was a real challenge to achieve within Kubernetes, but worth the effort.

This allows us to compete with some of the world’s largest stream processing systems, and together with our distributed Path Node platform, puts us in a position to effectively deliver an unrivalled internet intelligence, monitoring, analytics, and real-time streaming platform.

Sitting between Kafka and the Path Nodes, is a microservices API layer written in Elixir and C++. This layer, too, autoscales within Kubernetes.

In both our Production and Non-Production environments, we use EKS - the managed Kubernetes service provided by AWS. So far, we're big fans of it. We leverage the power of Auto Scaling Groups within AWS so that the K8S nodes autoscale to demand.

The Team

Our engineering team is composed of software engineers that were hand picked by myself. These are either people that I have worked with in the past, or are people that are well known within the Sydney technology sector, for example people who have either spoken at or organise various tech focused Meetups.

We are all fascinated by technology, and extremely passionate about it. When you mix a group of people who love tech, with some really great pieces of technology and an excellent idea as the driving force behind it, what you get is something that's truly beautiful. It's really rewarding to work with such smart people.

Our engineering team combines the right amount of expertise in Software Engineering, DevOps, Network Engineering and Information Security. Throughout this blog series, each team member will introduce themselves by writing a blog post, so stay tuned and you'll get to know them all a little better!

Final thoughts and latest updates

That's really it for the introduction. There is so much more that I want to talk about, but have it planned for separate articles.

Before wrapping this up, i'd like to share a little bit of recent progress.

We are finally in the stages where we are performing real world tests, load testing the platform from thousands of nodes distributed globally across the world and conducting various kinds of application performance testing and network testing. If you come from a network engineering or ISP background and have ever used a "Looking Glass" router, you'll be thoroughly impressed by our platform - performing various routing and BGP tests, traceroutes, testing TCP/UDP endpoint connectivity from multiple ISPs across the globe and getting real-time data back as it is rather powerful.

One of the other really cool things we're starting to recognise the power and potential of is sending custom HTTP payloads (IE: A POST request to a specific API endpoint) and expecting a certain response from that API, within a certain time threshold.

Pretty cool, right?

Right now, we have a NodeJS + Docker release ready to go and allowing us to perform functional and load testing, however we're planning on tying its public release with our Mobile application, which is near completion.

It's most of the way there, with some minor functionality changes and something I felt rather critical about, the User Interface.

Here is the new design for the mobile app. Pretty sweet, eh?

Okay guys, that's it for now! Stay tuned for our next blog post, where we'll be talking about our distributed compute processing and our mobile application.

In collaboration with Digital Cold ( @digital_cold) we fuzzed BSP map files for Counter Strike: Global Offensive leading to the discovery of a stack-based buffer overflow. We used the Basic Fuzzing Framework (BFF) to instrument and fuzz the game process and to perform initial crash triage with !exploitable. One of the many crashes we discovered was particularly exploitable. BFF generated a malformed .BSP file that triggered a Data Execution Prevention (DEP) exception in the csgo.exe process, meaning the instruction pointer of the process had been corrupted to execute a non-executable memory region. Through some reverse engineering and source code analysis, we discovered that the vulnerability corrupts an arbitrary amount of the stack based off a length field. By carefully controlling the amount of corruption and the corrupting data, we could overflow an on-stack vtable pointer. After being corrupted, the vtable can be redirected to achieve arbitrary code execution. This vulnerability is also remotely exploitable given that a game server could host a malicious map file and deliver it to a remote client.

From Crash to Code

Let's dig into the crash and show how we were able to triage from start to finish. We started from this following crash output:

Notice that 0x18ff191b is not in an executable region (hence the BUGCHECK_STR mentioning NX_FAULT). This indicates we have likely overflown some control flow structure, be that a saved return address or function pointer.

With this crash likely due to stack corruption, the previous stack frames may not be reliable. In fact, visiting filesystem_stdio+0x1090a in IDA leads no where. Luckily, visiting filesystem_stdio+0x580f leads to a real code location:

It appears that our crash is occurring in the sub_10010950 function. Great, now we have a crash location! Let's save some reverse engineering and try to correlate this assembly to source code. Further down in the function containing 0x580f, we find these string references:

Searching for one the "pack file" string on GitHub leads to the CZipPackFile::Prepare function in the Source engine. Reading this function and matching it to the IDA graph, we start to see some indications of a lack of bounds checking:

It so happens that DBGFLAG_ASSERT is not defined at compile time. Therefore, this assert is not present in release builds and fails to prevent a buffer overflow.

For the triage we performed above, Valve awarded us a bonus of $2,500. Source code greatly helped us with the root-cause analysis and saved hours of reverse engineering. Additionally, the interesting story of a compiled out Assert could have never been told without it.

The fix took roughly two months from the initial report to the public fix. This is a great turnaround time and further demonstrates Valve's commitment to fixing bugs in their core properties. For our efforts, Valve awarded us with a generous $12,500 bounty. Payouts like this motivate us to dig deeper to find more high impact security vulnerabilities.

Moving Forward

The attack surface on Gold Source and Source game engines is vast. We've only scratched the surface and plan to focus more on the network aspects of the games. Given the current mitigations (DEP + ASLR) it's difficult to create a working exploit for one-shot file-format exploits. A more interactive exploitation platform, such as a custom server, would allow us to perform multi-stage exploits incorporating an information leak to break ASLR.

If this peaked your interest, keep up-to-date with the latest discussion and research from path.network on our Telegram.

As Internet-powered businesses and services are becoming the norm within the global economy, it naturally follows that political realities will begin to impact this still nascent industry in an accelerated manner. This in mind, there is one recent political development in the United States that could potentially have disastrous effects on the most network-dependent technology companies.

On December 14, 2017 the FCC (Federal Communications Commission) voted - in a 3 to 2 decision - to repeal their enforcement of net neutrality. This is a repudiation of the agency’s 2015 regulatory decision, which was to ensure the equal treatment of ISP (Internet Service Provider) customers. Currently, there is none of this “net neutrality.”

In effect, net neutrality is the regulation of the Internet with egalitarian intentions. Net neutrality ensures that service providers can’t charge different rates for different internet data, can’t treat some media or content differently with regards to how traffic is handled, and can’t throttle bandwidth. These protections are now gone.

Net neutrality stops companies from slowing down or blocking access to competing sites. For instance, what keeps a major telecommunications carrier from creating their own streaming platform and then slowing or blocking access to streaming sites like Amazon or Netflix to deliberately stifle competition?

Lack of regulation begetting uncompetitive and unfair corporate action isn’t hypothetical at all. In fact, ISPs have a history of doing this. In 2005, Comcast slowed speeds (throttling) to some file sharing and torrent sites. In 2014, Verizon blocked access to Google Wallet to sway users to use Verizon’s own Isis Wallet. And while a name change might have been a better decision, the truth is that without net neutrality, the internet is not a truly free place.

An absolutely incredible amount of cryptocurrency transactions occur via exchanges. If so inclined, ISPs could target cryptocurrency exchanges, slowing them down or banning them altogether. Assuming cryptocurrencies continue their historic rise, there will be noticeable monetary incentive for ISPs to invest in or develop their own exchanges and subsequently limit access to their competition. In addition, they could throttle connections to blockchain websites and the user interface of various blockchain applications they deem “competition.” A simple action such as slowing down the API (Application Programming Interface) that the user interacts with would slow the entire application. To convey this concept in different terms, it doesn’t matter how fast and smooth Candy Crush runs if the entire App Store is unusable.

If there’s one thing being revealed in this increasingly technology-focused era, it is that the need for decentralization is more critical and necessary than ever. We as a worldwide community need decentralization - we need to be empowered and feel that we have a voice within a system. We have the power to protect ourselves, our assets, and our future. This revocation of net neutrality is a wake-up call.

Due to the reliance of the modern economy on Internet traffic and its proper facilitation, it’s only logical to think about networks that you do not or cannot control.

This lack of control would naturally be a “weak point” in such a company’s flow of business and, in one example, could lead to efforts in measuring the outbound traffic being delivered from data centers via various Internet Service Providers (ISPs) - the companies we, as customers, give payment to in exchange for access to the internet.

But what about attempting to fully understand the impact of external networks and services from the direct point of view of your customers? Your users rely on a domino chain of providers including DNS, CDN, DDoS mitigation, and Internet Service Providers (ISP’s) to get to your site.

So how exactly can you determine the performance of these providers? Since all of the above providers are multi-tenant and always on, what happens to your site’s performance if some other customer of your DDoS mitigation provider is getting battered by an attack - will your users suffer too? What if DNS response time goes from 20 ms to 250 ms? Who do you go to when the problem is happening somewhere “out there”? You need to know the answer to these questions, from the perspective of all of your customers, no matter where they are.

You can’t use passive network monitoring data to answer these questions, simply because you can’t collect flow, pcap (Packet Capture), or SNMP (Simple Network Management Protocol) data from networks that you don’t control. Even APM (Application Performance Management), as wonderful as it is, has a limited ability to give you true insight into the root causes of network issues.

This is a hard lesson for any corporation. For instance, think about the havoc this lack of ability to determine root causation in network issues could cause a major bank. Imagine for just a moment what it would be like if users couldn’t access their online banking site after multiple attempts. Most online banks utilize APM tools, but these are hard-pressed to glean any true insight from because the problem - in most cases - isn’t the website code or internal infrastructure.

In these cases, when you can’t effectively collect passive data, just call Path Network!

In our experience, we’ve found that there a few key requirements for effective network monitoring:

You need the perspective of every user. A user could be someone in an office or at a remote location. A user could also be a microservice sitting in a datacenter, AWS (Amazon Web Services), Azure, or GCP (Google Cloud Platform).

Applications and networks are equally important. When you’re dealing with networks and services that you don’t own or control, you need both sets of data, and the ability to visually correlate the two. Singular performance indicators analyzed separately are not particularly insightful and certainly not too helpful in the real world.

You need all of the application and network measurements continuously analyzed together. In addition, you don’t want your Tech team doing that in their heads, Excel, or on paper. Correlative analysis needs to be adaptive, visual, and shareable in order to be helpful. It is imperative to utilize this sort of visual data to get both internal and external teams to act together to solve problems and optimize service delivery.

You may not own many of the networks, applications, or services that your business depends on, but that doesn’t mean that you escape responsibility for the delivery of services. In-depth network analysis will help you mitigate the large “weak point” that network issues can rise to become. If you want to learn more please join us on Telegram: https://t.me/PathNetworkEnglish