OASIS TC Open Repository: Match STIX content against STIX patterns
Home Page: https://github.com/oasis-open/cti-pattern-matcher
License: BSD 3-Clause "New" or "Revised" License
My pattern combines two matching patterns, but return no match, what am I missing?
~/barha/obs# stix2-matcher -p p -f o.json
NO MATCH: [(windows-registry-key:key = 'HKLM\\\\SYSTEM\\\\CurrentControlSet\\\\Control\\\\MiniNt' AND x-event:action = 'CreateKey')]
MATCH: [(x-event:action = 'CreateKey')]
MATCH: [(windows-registry-key:key = 'HKLM\\\\SYSTEM\\\\CurrentControlSet\\\\Control\\\\MiniNt')]
AND pattern:
"[(windows-registry-key:key = 'HKLM\\SYSTEM\\CurrentControlSet\\Control\\MiniNt' AND x-event:action = 'CreateKey')]"
pattern 1:
"[(windows-registry-key:key = 'HKLM\\SYSTEM\\CurrentControlSet\\Control\\MiniNt')]"
pattern 2:
"[(x-event:action = 'CreateKey')]"
using the following observed data -
{
"id": "observed-data--107c9a2d-12e9-4599-8a0c-2021a88b472d",
"type": "observed-data",
"created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae3ee",
"created": "2020-08-26T13:23:57.728Z",
"modified": "2020-08-26T13:23:57.728Z",
"objects": {
"0": {
"type": "windows-registry-key",
"key": "HKLM\\SYSTEM\\CurrentControlSet\\Control\\MiniNt"
},
"1": {
"type": "process",
"name": "powershell.exe",
"pid": 8816,
"x_ecs_entity_id": "{747f3d96-6e04-5f45-9d00-000000003800}",
"binary_ref": "3",
"x_ecs_event_ref": "6"
},
"2": {
"type": "process",
"child_refs": [
"1"
]
},
"3": {
"type": "file",
"name": "powershell.exe",
"parent_directory_ref": "4"
},
"4": {
"type": "directory",
"path": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0"
},
"5": {
"type": "x-ecs-host",
"hostname": "MSEDGEWIN10",
"os_name": "Windows 10 Enterprise Evaluation",
"os_version": "10.0",
"os_platform": "windows",
"ip": [
"fe80::c50d:519f:96a4:e108",
"10.0.2.15"
],
"name": "MSEDGEWIN10",
"id": "747f3d96-68a7-43f1-8cbe-e8d6dadd0358",
"mac": [
"08:00:27:e6:e5:59"
],
"architecture": "x86_64"
},
"6": {
"type": "x-event",
"code": 12,
"provider": "Microsoft-Windows-Sysmon",
"created": "2020-08-25T20:01:28.591Z",
"kind": "event",
"module": "sysmon",
"action": "CreateKey"
}
},
"first_observed": "2020-08-25T20:01:28.567Z",
"last_observed": "2020-08-25T20:01:28.567Z",
"number_observed": 1
}
This is what is causing the build failures; pre-commit no longer supports Python 3.3, which is already end-of-life.
Hi everyone,
While working with STIX patterns we thought about how it would be possible to model randomized values which re-appear across multiple Observable objects. Let's consider the following example:
We want to model a pattern that describes the behaviour of a malware sample. The sample is executed multiple times and we get the following Observables from the runtimes;
Runtime 1: file:name = 'foo', mutex:name = 'Global\foo'
Runtime 2: file:name = 'bar', mutex:name = 'Global\bar
Runtime 3: file:name = 'baz', mutex:name = 'Global\baz'
It is obvious we need a pattern, since the values differ between each runtime, so the resulting STIX pattern may look like this:
[file:name MATCHES '[a-z]{3}]' AND [mutex:name MATCHES 'Global\\[a-z]{3}]'
The pattern perfectly accommodates the fact that the sample randomizes the used values for each runtime. However, we lose the information that the file and mutex objects always share the same name within the same runtime.
An obvious solution is the use of variables within patterns. We propose a solution that utilizes named capture groups, which can be defined within regular expressions. The same pattern from above, but with named capture groups looks like this:
[file:name MATCHES '(?P<var>[a-z]{3})]' AND [mutex:name MATCHES 'Global\\(?P<var>[a-z]{3})]'
We have defined a variable var, which indicates that the file-name and mutex-name regexes describe the same value. Since named capture groups are a feature of regular expressions, this approach is fully backwards compatible with existing STIX pattern matching implementations. We call a pattern with such variables inter-observable patterns.
We believe this feature to be beneficial to a broader community. We woud like to contribute our solution for the issue outlned above.
The matcher doesn't appear to work with STIX 2.1 if using object_refs instead of a 2.0-style Observable Container.
± stix2-matcher -p examples/pattern -f examples/good_obs.json
PASS: [ software:vendor = 'nginx' AND software:version = '1.13.2' ]
± echo $?
0
± stix2-matcher -p examples/pattern -f examples/bad_obs.json
FAIL: [ software:vendor = 'nginx' AND software:version = '1.13.2' ]
± echo $?
0
Is this intentional? I realize there can be multiple patterns, and multiple matches, but shouldn't it exit with 1 if there are any fails?
I had considered NOT to count as part of the operator, when interpreting the spec section 4.2.1 requirement regarding incompatible types. The spec says only != evals to True if types are incompatible. I interpreted it to mean for example, that both MATCHES and NOT MATCHES eval to False. This is how the unit tests are written. Upon a recent re-reading of that section though, I'm not so sure. The NOT operator is described in the second paragraph as a "modifier" to the comparison operator, which may imply that it's not considered part of the operator. That may mean that only MATCHES should eval to False on incompatible types; NOT MATCHES should negate that, resulting in evaluation to True.
How should this work?
Support the ability to "precompile" the pattern, so that repeated matches of the same pattern do not have to parse the pattern over and over again.
Something like how re module does it:
mat = PatternMatcherObject(pattern)
objs = mat.match(inpobjects)
objs2 = mat.match(inpobjects2)
This is new to STIX 2.1 and is currently missing from the STIX 2.1 implementation. https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html#_t11hn314cr7w
This may be needed to clear up in the spec, but IMO, the results returned for this are not correct.
Given the pattern:
[ a:b[*] NOT = 22 ]
and the object { "type": "a", "b": [ 22, 443 ] }
I believe it should NOT match, as it should be the equivalent to NOT (a:b[*] = 22). There was some confusion about this before, and we may have not made the correct choice where we put the NOT operator.
The spec says:
A Comparison Operator MAY be preceded by the modifier NOT, in which case the resultant Comparison Expression is logically negated.
It does not say the comparison operator is logically negated, but the entire expression is.
But you can see in the verbose output from the matcher, that it is negating the comparison, NOT the expression:
exitObjectType (a): push {0: {u'0': [{u'b': [22, 443], u'type': u'a'}]}}
exitFirstPathComponent (b): pop {0: {u'0': [{u'b': [22, 443], u'type': u'a'}]}}
exitFirstPathComponent (b): push {0: {u'0': [[22, 443]]}}
exitIndexPathStep (*): pop {0: {u'0': [[22, 443]]}}
exitIndexPathStep (*): push {0: {u'0': [22, 443]}}
exitPropTestEqual (NOT = 22): pop {0: {u'0': [22, 443]}}
exitPropTestEqual (NOT = 22): push {0: set([u'0'])}
exitObservationExpression (simple): pop {0: set([u'0'])}
exitObservationExpression (simple): push [(0,)]
MATCH: [ a:b[*] NOT = 22 ]
It should match on the 22 w/ the =, and then negate it to false via the NOT, instead it is != matching on the 443, and returning true.
Add badges for: Travis CI, Version and Coverage
Apparently pypi can't reach out to URLs outside of PyPi when installing any pypi package(according to pypa/pip#6301). So i'm wondering if there's any plan to publish stix2-matcher in pypi to make this process easier.
Hi There,
I can't seem to get wildcards working as per the 2.0 spec when I import the library into my code (both LIKE and MATCHES not working for me):
Example Code:
from stix2matcher import matcher
obs = {
"created":"2017-08-29T08:26:22.135105Z",
"first_observed":"2017-08-29T08:25:44Z",
"id":"observed-data--43d8af75-216d-414a-a156-50eeba54e4c5",
"last_observed":"2017-08-29T08:25:44Z",
"modified":"2017-08-29T08:26:22.135105Z",
"number_observed":1,
"objects":{
"0":{
"type":"domain-name",
"value":"i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net"
}
},
"type":"observed-data",
"@version":"1",
"@timestamp":"2017-08-29T08:26:22.706Z"
}
# Dont Work
print matcher.match("[domain-name:value LIKE '%%cedexis%%']",[obs,])
print matcher.match("[domain-name:value LIKE '%cedexis%']",[obs,])
print matcher.match("[domain-name:value MATCHES '.*cedexis.*']",[obs,])
print matcher.match("[domain-name:value MATCHES '^.*cedexis.*$']",[obs,])
# Works
print matcher.match("[domain-name:value = 'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']",[obs,])
Verbose Output:
exitObjectType (domain-name): push {0: {'0': [{'type': 'domain-name',
'value': 'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): pop {0: {'0': [{'type': 'domain-name',
'value': 'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): push {0: {'0': ['i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestLike (%%cedexis%%): pop {0: {'0': ['i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestLike (%%cedexis%%): push {}
exitObservationExpression (simple): pop {}
exitObservationExpression (simple): push []
[]
exitObjectType (domain-name): push {0: {'0': [{'type': 'domain-name',
'value': 'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): pop {0: {'0': [{'type': 'domain-name',
'value': 'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): push {0: {'0': ['i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestLike (%cedexis%): pop {0: {'0': ['i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestLike (%cedexis%): push {}
exitObservationExpression (simple): pop {}
exitObservationExpression (simple): push []
[]
exitObjectType (domain-name): push {0: {'0': [{'type': 'domain-name',
'value': 'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): pop {0: {'0': [{'type': 'domain-name',
'value': 'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): push {0: {'0': ['i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestRegex ('.*cedexis.*'): pop {0: {'0': ['i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestRegex ('.*cedexis.*'): push {}
exitObservationExpression (simple): pop {}
exitObservationExpression (simple): push []
[]
exitObjectType (domain-name): push {0: {'0': [{'type': 'domain-name',
'value': 'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): pop {0: {'0': [{'type': 'domain-name',
'value': 'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): push {0: {'0': ['i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestRegex ('^.*cedexis.*$'): pop {0: {'0': ['i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestRegex ('^.*cedexis.*$'): push {}
exitObservationExpression (simple): pop {}
exitObservationExpression (simple): push []
These patterns match when called from the command line, so I imagine its something to do with how i'm importing the library.
Patterns.txt:
[domain-name:value LIKE '%cedexis%']
[domain-name:value MATCHES '.*cedexis.*']
[domain-name:value MATCHES '^.*cedexis.*%']
obs.json:
[{
"created":"2017-08-29T08:26:22.135105Z",
"first_observed":"2017-08-29T08:25:44Z",
"id":"observed-data--43d8af75-216d-414a-a156-50eeba54e4c5",
"last_observed":"2017-08-29T08:25:44Z",
"modified":"2017-08-29T08:26:22.135105Z",
"number_observed":1,
"objects":{
"0":{
"type":"domain-name",
"value":"i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net"
}
},
"type":"observed-data",
"@version":"1",
"@timestamp":"2017-08-29T08:26:22.706Z"
}]
Result:
$> stix2-matcher -p patterns.txt -f obs.json
MATCH: [domain-name:value LIKE '%cedexis%']
MATCH: [domain-name:value MATCHES '.*cedexis.*']
MATCH: [domain-name:value MATCHES '^.*cedexis.*$']
Verbose:
exitObjectType (domain-name): push {0: {u'0': [{u'type': u'domain-name',
u'value': u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): pop {0: {u'0': [{u'type': u'domain-name',
u'value': u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): push {0: {u'0': [u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestLike (%cedexis%): pop {0: {u'0': [u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestLike (%cedexis%): push {0: set([u'0'])}
exitObservationExpression (simple): pop {0: set([u'0'])}
exitObservationExpression (simple): push [(0,)]
MATCH: [domain-name:value LIKE '%cedexis%']
exitObjectType (domain-name): push {0: {u'0': [{u'type': u'domain-name',
u'value': u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): pop {0: {u'0': [{u'type': u'domain-name',
u'value': u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): push {0: {u'0': [u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestRegex ('.*cedexis.*'): pop {0: {u'0': [u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestRegex ('.*cedexis.*'): push {0: set([u'0'])}
exitObservationExpression (simple): pop {0: set([u'0'])}
exitObservationExpression (simple): push [(0,)]
MATCH: [domain-name:value MATCHES '.*cedexis.*']
exitObjectType (domain-name): push {0: {u'0': [{u'type': u'domain-name',
u'value': u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): pop {0: {u'0': [{u'type': u'domain-name',
u'value': u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net'}]}}
exitFirstPathComponent (value): push {0: {u'0': [u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestRegex ('^.*cedexis.*$'): pop {0: {u'0': [u'i2-ymeamdnxvpofijvkluyxccakvwpnua.init.cedexis-radar.net']}}
exitPropTestRegex ('^.*cedexis.*$'): push {0: set([u'0'])}
exitObservationExpression (simple): pop {0: set([u'0'])}
exitObservationExpression (simple): push [(0,)]
MATCH: [domain-name:value MATCHES '^.*cedexis.*$']
What is the best approach to achieve this?
Cheers
Adam
If you add the following test case to test_binary.py (https://github.com/oasis-open/cti-pattern-matcher/blob/master/stix2matcher/test/test_binary.py ):
"[binary_test:name_bin MATCHES 'alice' ]",
you will get a failure, even though it should work. This is explicitly allowed in the spec via the statement:
In the case that the property is binary (e.g., the property name ends in _bin or _hex), then the UNICODE flag MUST NOT be specified.
The files README.md and CONTRIBUTING.md contain HTML and are not in the MD format. They should either be renamed (less preferable) or be converted to proper MarkDown (text) (most preferable).
When I get the CLA I'll work on this, but it'd be nice if this gets converted sooner rather than later.
So, a generated stix2 observed data is not compatible w/ the pattern matcher code. See the attached file.
t.txt
When run, it raises:
$ python t.py
Traceback (most recent call last):
File "/Users/jmg/work/python-indicator/t.py", line 8, in <module>
print(repr(stix2matcher.matcher.match("[ artifact:payload = 'pass' ]", [ od ])))
File "/Users/jmg/work/python-indicator/p/lib/python3.9/site-packages/stix2matcher/matcher.py", line 2349, in match
return compiled_pattern.match(observed_data_sdos, verbose)
File "/Users/jmg/work/python-indicator/p/lib/python3.9/site-packages/stix2matcher/matcher.py", line 2322, in match
matcher = MatchListener(observed_data_sdos, verbose)
File "/Users/jmg/work/python-indicator/p/lib/python3.9/site-packages/stix2matcher/matcher.py", line 1008, in __init__
self.__time_intervals.append((_str_to_datetime(sdo["first_observed"]),
File "/Users/jmg/work/python-indicator/p/lib/python3.9/site-packages/stix2matcher/matcher.py", line 474, in _str_to_datetime
if not ignore_case and any(c.islower() for c in timestamp_str):
TypeError: 'STIXdatetime' object is not iterable
The number_observed attribute of observed-data incurs a linear cost to the matcher which seems to be related to the way it is used internally to multiply the SDO. Below are some profiles of the same test but using 1000 vs 10000 number_observed. The profiles look a bit different just because the profiler includes more in the call graph due to longer execution time.
The examples below use 1000 & 10000 just to be illustrative with a single SDO (and it makes it easier to capture the relevant bits in the profile). I realize that is extreme, but smaller values of number_observed in a larger SDO list could also add up.
1 SDO with 1000 number_observed * 50 patterns
1 SDO with 10000 number_observed * 50 patterns
The SDO list looks like
[
{
"id": "observed-data--107c9a2d-12e9-4599-8a0c-2021a88b472d",
"type": "observed-data",
"created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae3ee",
"last_observed": "2020-08-25T20:01:28.567Z",
"first_observed": "2020-08-25T20:01:28.567Z",
"number_observed": 10000,
"created": "2020-08-26T13:23:57.728Z",
"modified": "2020-08-26T13:23:57.728Z",
"objects": {
"0": {
"type": "windows-registry-key",
"key": "HKLM\\SYSTEM\\CurrentControlSet\\Control\\MiniNt",
},
"1": {
"type": "process",
"name": "powershell.exe",
"pid": 8816,
"x_ecs_entity_id": "{747f3d96-6e04-5f45-9d00-000000003800}",
"binary_ref": "3",
"x_ecs_event_ref": "6",
},
"2": {"type": "process", "child_refs": ["1"]},
"3": {
"type": "file",
"name": "powershell.exe",
"parent_directory_ref": "4",
},
"4": {
"type": "directory",
"path": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0",
},
"5": {
"type": "x-ecs-host",
"hostname": "MSEDGEWIN10",
"os_name": "Windows 10 Enterprise Evaluation",
"os_version": "10.0",
"os_platform": "windows",
"ip": ["fe80::c50d:519f:96a4:e108", "10.0.2.15"],
"name": "MSEDGEWIN10",
"id": "747f3d96-68a7-43f1-8cbe-e8d6dadd0358",
"mac": ["08:00:27:e6:e5:59"],
"architecture": "x86_64",
},
"6": {
"type": "x-event",
"code": 12,
"provider": "Microsoft-Windows-Sysmon",
"created": "2020-08-25T20:01:28.591Z",
"kind": "event",
"module": "sysmon",
"action": "CreateKey",
},
},
}
]Where number_observed is changed between the two tests above.
Hi,
Just a curious user of this library. I used a file with this Observable SDO (this is an excerpt of the example given in matcher.py):
{ "type": "observed-data", "id": "observed-data--b67d30ff-02ac-498a-92f9-32f845f448cf", "created": "2016-04-06T19:58:16.000Z", "modified": "2016-04-06T19:58:16.000Z", "first_observed": "2015-12-21T19:00:00Z", "last_observed": "2015-12-21T19:00:00Z" , "number_observed": 2, "objects": { "0": { "type": "file", "hashes": { "SHA-256": "d774bda24d8c30be97ecb6d3d8133ed83d6ddfa202f1e466b8e62da7684480f3" } }, "1": { "type": "file", "mime_type": "application/zip", "hashes": { "MD5": "22A0FB8F3879FB569F8A3FF65850A82E" } } } }
And this is the pattern that I used:
[file:mime_type = 'application/zip' AND file:hashes.'MD5' = '22A0FB8F3879FB569F8A3FF65850A82E']
Running this through the stix2-matcher.exe gave this result:
Traceback (most recent call last):
File "build\bdist.win32\egg\stix2matcher\matcher.py", line 2195, in main
File "build\bdist.win32\egg\stix2matcher\matcher.py", line 2154, in match
File "build\bdist.win32\egg\stix2matcher\matcher.py", line 2124, in match
File "build\bdist.win32\egg\stix2matcher\matcher.py", line 941, in __init__
TypeError: string indices must be integers
Tracing down the error to the source code, it was due to this line:
number_observed = sdo["number_observed"]
It is possible that it couldn't recognize my "number_observed" as an integer, which is very weird to me. It is likely an error on my end but I am not too sure how to mitigate this error from appearing. I have validated both the pattern and the SDO with the various libraries provided by OASIS.
It will be awesome if I could get a hint of what is going on so I can further investigate on my own. I am still exploring STIX and I might be wrong that this may be a bug, but I do want to learn what I might have misunderstood.
Figure out how, given a pattern to generate a corse filter for the pattern. Like only observables w/ a cyber object that has type file.
This would let us pre filter the observable data before being passed to the matcher to help make it faster.
Install requires stated 'antlr4-python3-runtime==4.7 ; python_version >= "3"', but stix2-patterns has antlr4-python3-runtime~=4.8.0; which creates a conflict while installing setup.py. Here's the error-
ERROR: stix2-patterns 1.3.0 has requirement antlr4-python3-runtime~=4.8.0; python_version >= "3", but you'll have antlr4-python3-runtime 4.7 which is incompatible.
Is it possible to bump up the version of antlr4-python3-runtime to 4.8 ?
if you add the line:
r"[binary_test:name MATCHES '\x61lice' ]",
NB: the r is needed, otherwise python will escape the \x61 to an a, and the parser will not see backslash 61 (which is the same as the letter a).
To the first set of ops in test_binary.py, you'll get the following:
E ParseException: 1:26: mismatched input ''' expecting StringLiteral
A similar error is seen when passing this to the pattern validator. If the backslashe is removed, then the pattern will be parsed properly.
Things to consider:
number_observed is 1 (since there was no multiplicity on CybOX containers. We should generalize that in cases where trying to match REPEATS x TIMES patterns.cybox-container type is gone, so we should just handle STIX observed-data objects, which contain their own timestamps. This will affect WITHIN and FOLLOWEDBY patterns.Replace with "Cyber Observables"
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.