Challenge update
parent
c337680836
commit
d56771f18f
|
|
@ -1,19 +0,0 @@
|
|||
# CCTF Challenge for Polkadot Metaverse Championship
|
||||
|
||||
## Description
|
||||
CCTF is a Capture the Flag (CTF) game. CTF in computer security is an exercise in which 'flags' are secretly hidden in purposefully-vulnerable programs or websites. Competitors steal flags either from other competitors (attack/defense-style CTFs) or from the organizers (jeopardy-style challenges).
|
||||
|
||||
From CCTF volume 9, we have started to use a decentralized system: Solidity smart contract deployed and players send signed messages. Flags became private keys. We replaced CTFd to our smart contract, but it needs improvements.
|
||||
|
||||
## Task
|
||||
|
||||
Improve the CCTF smart contract. You can improve the flag submission (eg. fix the hidden vuln from the last game), add features or create a frontend. Be creative, make something useful.
|
||||
|
||||
|
||||
## Links, sources
|
||||
|
||||
Solidity smart contract deployed address is 0x36a1424da63a50627863d8f65c0669da7347814a - find on Polygon network.
|
||||
|
||||
Website: https://cryptoctf.org/
|
||||
|
||||
Blog the ECDSA forgery: https://cryptoctf.org/2022/09/11/writeup-of-flag-submission-forgery-by-si/
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
# KILT Protocol Challenge for Polkadot Metaverse Championship
|
||||
|
||||
## Description
|
||||
With the birth of the metaverses digital identities are will be an integral building block of Web3.
|
||||
We have seen identity abused on the application layer in Web2, let's not do the same mistake when building out the metaverse.
|
||||
DIDs are the decentralized identifiers for the future of Web3, and this challenge is to make them usable for the metaverse.
|
||||
|
||||
## Task
|
||||
- Integrate KILT DIDs into a metaverse project as an identity layer (e.g. Kusamaverse).
|
||||
- Add authentication to the metaverse
|
||||
- Be creative!
|
||||
- BONUS: make a PR into the metaverse project's repo
|
||||
|
||||
## Links, sources
|
||||
docs.kilt.io
|
||||
kusama.momentum.xyz
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
# Momentum/Kusamaverse Challenge for Polkadot Metaverse Championship
|
||||
|
||||
## Description
|
||||
This is a creative challenge, we recommend to use it as a proposal challenge.
|
||||
|
||||
## Task
|
||||
Get into Kusamaverse and figure out how you'd improve it or rebuild it from scratch to create an even better metaverse experience. Remember, Kusamaverse is focused on collaboration and working together. How would you improve it?
|
||||
|
||||
## Links, sources
|
||||
https://kusama.momentum.xyz/
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
# Judge&Mentor Challenge for Polkadot Metaverse Championship
|
||||
|
||||
## Description
|
||||
Fun challenge for the judges and mentors. Totally optional, but it is cool to show-off your skills! Show everyone why you are in the position! :)
|
||||
|
||||
## Task
|
||||
1. Play an arcade or VR game with other judges/mentors.
|
||||
2. Record the experience on blockchain (anything works, be creative, try to make it fun)
|
||||
|
||||
Tip: you could use some strange languages, encoding or fun, unusual practices to solve this. Eg. Bitcoin's smart contract or this:
|
||||
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++
|
||||
|
||||
## Links, sources
|
||||
It doesn't apply here :) You have the whole location, show us something cool!
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
# Privacy Challenge for Polkadot Metaverse Championship
|
||||
|
||||
## Description
|
||||
This is a privacy research challange. Take is as a proposal.
|
||||
|
||||
## Task
|
||||
Do a research on privacy and what data is taken by the chosen project - list below. You need to test what kind of data can be logged and where by the service provider, for example: does the backend receive your browser user-agent, screen resolution, battery state, etc. We know some of the projects listed here have serious issues, but a clear collection of what data is taken and where would it be stored could make things more transparent and increase awareness.
|
||||
|
||||
So the task is to do the research, create list about data sent to the project servers/nodes and draw a topology. Don't spend on it more than an hour.
|
||||
|
||||
Ideas on what to look for:
|
||||
- Data in the HTTP/API requests
|
||||
- Data in the WSS channels
|
||||
- Network data
|
||||
- Think about timing and even if you have multiple addresses, balance checks can give a good base for statistics on which addresses belong to the same wallet/browser
|
||||
- Consider what would happen if you use the service through proxy/TOR/etc
|
||||
|
||||
## Links, sources
|
||||
https://kusama.momentum.xyz/
|
||||
https://polkadot.js.org/
|
||||
https://www.talisman.xyz/
|
||||
https://metamask.io/
|
||||
https://acala.network/
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
# Proposal Template - Challenge Name
|
||||
|
||||
## Team name
|
||||
Add your team's name here.
|
||||
|
||||
## Short description of your proposal
|
||||
A few sentences on what your team is proposing.
|
||||
|
||||
## Technical details
|
||||
Explain the technical details and how you'd solve the challenge. Optionally you can add pseudocode.
|
||||
|
||||
## Topology
|
||||
|
||||
Please provide a drawn topology, you can use https://draw.io/
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
# RMRK Challenge for Polkadot Metaverse Championship
|
||||
|
||||
## Description
|
||||
RMRK (pronounced "remark") is a set of NFT legos that give NFTs infinite extensibility, hosted on the Kusama blockchain, Polkadot's canary network, without the need for parachains or smart contracts.
|
||||
|
||||
## Task
|
||||
|
||||
Be creative, chose one from below and implement it in the 24 hours or create a proposal.
|
||||
|
||||
-Ticketing system as in docs - for metaverse events (https://docs.rmrk.app/usecases/ticketing)
|
||||
-Skill system as in docs (https://docs.rmrk.app/ownershipxp)
|
||||
-An atomic swap widget for RMRK nfts
|
||||
-A replicable collection indexer which is installable on any machine locally and only indexes the desired collections, for building project-specific markets
|
||||
-A MV smart-city in Kanaria Skybreach - with equippable buildings and roads
|
||||
-Anything from docs usecases (https://docs.rmrk.app/usecases)
|
||||
|
||||
## Links, sources
|
||||
https://www.rmrk.app/
|
||||
|
|
@ -1,130 +0,0 @@
|
|||
# Unit Challenge for Polkadot Metaverse Championship
|
||||
|
||||
## Unit Network - Collaboration Track Challenges
|
||||
|
||||
Participants may choose any one of the three challenges below to complete in a 24hr period.
|
||||
|
||||
Each challenge relates to a combination and/or extension of existing Substate palettes.
|
||||
|
||||
An emphasis is to provide the freedom and incentive for each participant to produce something useful related to any of the three options below. As such these are generic overviews to explain the desired application of each palette.
|
||||
|
||||
Participants will be judged on the novelty, simplicity and security of their solutions. Please chose only one from the challenges below.
|
||||
|
||||
## 1. Badges Module
|
||||
|
||||
### Challenge
|
||||
|
||||
Create the simplest and most secure Badges Module in 24hrs. The three essential components are:
|
||||
|
||||
- Non-transferrable once received from the creator
|
||||
-¢ Can be set to expire within a specified timeframe
|
||||
-¢ Can be batch transferred to selected account / wallets
|
||||
|
||||
Note: Any additional parameters that enhance the usability and feature set of the Badges Module will also be considered favourably by the judges.
|
||||
|
||||
|
||||
### Overview
|
||||
|
||||
The Badges Module provides functionality for asset management of ‘conditional’ fungible asset classes akin to Proof of Attendance Protocol tokens (POAPs) and Soulbound Tokens (SBTs) including:
|
||||
|
||||
-¢ Asset Issuance
|
||||
-¢ Asset Transfer (limited to a single transfer, can be batch transferred)
|
||||
-¢ Asset Expiry (set by creator but not required)
|
||||
-¢ Asset Destruction (if received but unwanted)
|
||||
|
||||
|
||||
### Terminology
|
||||
|
||||
- Asset Issuance: The creation of a new asset instance
|
||||
- Asset Transfer: The action of transferring an asset instance from one account to another
|
||||
- Asset Burning: The destruction of an asset instance
|
||||
- Fungible Asset: An asset whose units are interchangeable
|
||||
- Conditional Fungible Asset: An asset whose units are interchangeable but have conditions set by the creator to specify functionality
|
||||
|
||||
|
||||
### Goals
|
||||
|
||||
The badges system in Substrate is designed to make the following possible:
|
||||
|
||||
- Issue a conditional asset to it’s creators account
|
||||
- Move asset to another account (one time) non-transferable after being received
|
||||
- Optionality to set an expiry date of the asset after which it is burned and removed from the total supply.
|
||||
- Remove an accounts balance of an asset when requested by the asset creator and update the assets total supply.
|
||||
|
||||
|
||||
### Usage
|
||||
|
||||
The following example shows how to use the Badges Module in your runtime by exposing public functions to:
|
||||
|
||||
- Issue a new conditional fungible asset set for a badge distribution event (airdrop)
|
||||
- Query the conditional fungible asset holding balance of an account
|
||||
- Query the total supply of a fungible asset that has been issued
|
||||
|
||||
|
||||
### Use-cases
|
||||
|
||||
Similar to SBTs and POAPs, the Badges Module may be used to:
|
||||
|
||||
- Issue non-transferrable certificates (badges) to graduates of a course or program (Additionally with an option for the badges to expire, requiring the graduates to do a course refresher or to earn a new valid / current badge.)
|
||||
|
||||
- Issue non-transferrable proof-of-attendance at an event
|
||||
|
||||
- Issue a non-transferrable proof-of-participation / position in a community, team or initiative
|
||||
|
||||
- Issue a non-transferrable ticket to access to an event
|
||||
|
||||
|
||||
## 2. Subscription Module
|
||||
|
||||
###Challenge
|
||||
|
||||
Create the simplest and most secure Subscription Module in 24hrs. The three essential components are:
|
||||
|
||||
- Allow authorisation of a recurring fungible asset debit, signed in a single transaction based on a time period set by subscription creator
|
||||
- Subscription can be cancelled on either side, by the user wallet or subscription creator
|
||||
- Query the success of each recurring asset transfer with a clear output value
|
||||
|
||||
Note: Any additional parameters that enhance the usability and feature set of the Subscription module will also be considered favourably by the judges.
|
||||
|
||||
### Overview
|
||||
|
||||
The subscription module provides functionality to create an automated recurring asset debit from authorised wallets for a set period of time, or until cancelled by the wallet owner or subscription creator including:
|
||||
|
||||
- Subscription Creation
|
||||
- Subscription Details
|
||||
- Subscription Plan
|
||||
- Subscription Start Date
|
||||
- Subscription Expiry Date
|
||||
- Subscription Amount
|
||||
- Subscription Period
|
||||
- Subscription Period Description
|
||||
- Subscription Unique
|
||||
- Subscription Cancellation
|
||||
|
||||
### Terminology
|
||||
|
||||
- Subscription Creation: The creation of a new subscription instance
|
||||
- Subscription Details: Holds the details of the subscription instance
|
||||
- Subscription Plan: Type of subscription plan
|
||||
- Subscription Start Date: (Optional) Date that the user will first be billed. (will default to the day the subscription is created if no startDate is specified)
|
||||
- Subscription Expiry Date: (Optional) Date the last payment is processed
|
||||
- Subscription Amount: Value in defined asset that the user pays at specified frequency
|
||||
- Subscription Period: How often the user will be billed
|
||||
- Scheduled Asset Transfer: The Automated Direct debit of assets from an authorised user wallet to a wallet defined by the subscription creator
|
||||
- Subscription Unique: This value allows a single account to have more than one subscription
|
||||
- Subscription Cancellation: Can be cancelled by either user wallet or subscription creator
|
||||
|
||||
### Goals
|
||||
|
||||
The Subscription module in Substrate is designed to make the following possible:
|
||||
|
||||
- Create a recurring debit contract between user wallets and a subscription creator
|
||||
- Define subscription parameters
|
||||
- Query the success of each recurring asset transfer with a clear output value
|
||||
|
||||
|
||||
### Use-cases
|
||||
|
||||
- Create an automatic, token powered paywall to manage access to content or communities
|
||||
|
||||
- Create a community / patron subscription model
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
## search&ink! challenge
|
||||
|
||||
This challenge has four requirements to pass:
|
||||
|
||||
1. Map the services behind 45.77.137.182 and a way to connect (Alice helps!)
|
||||
2. Find the flag on-chain! Format as in other challenges PMC{...}
|
||||
3. Deploy the flipper ink! smart contract from your player DOT address (the one you use in the prequalifer registration form) on 45.77.137.182
|
||||
4. Automate the coin clip function call and share the code through the registration form.
|
||||
|
||||
This challenge requires you to have a basic understanding of Substrate and ink! smart contracts.
|
||||
|
||||
Please make sure to upload your solution through the form when you submit it - a text file is enough with a short explanation.
|
||||
|
||||
_Keccak256: 0x82703a464305aad655e2eb617f31e6e57b7e959bf8528f1d3b5968cc02ed60ac_
|
||||
|
||||
_Challenge author: six_
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
## Kusamaverse challenge
|
||||
|
||||
This is a very simple challenge. Just find the Metaverse Championship space in the Kusamaverse and you will know what to do from there.
|
||||
[Kusamaverse Link](https://kusama.momentum.xyz/)
|
||||
|
||||
You don't need to share any code or text for this challenge, just share share the flag.
|
||||
|
||||
_Keccak256: 0x896c90f019d0aaa7977ce81c7d7299b1b43d302295f2d567509ab7e3060a797f_
|
||||
|
||||
_Challenge author: six_
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
[package]
|
||||
name = "pmc"
|
||||
version = "0.1.0"
|
||||
edition = "2021"
|
||||
|
||||
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
|
||||
|
||||
[dependencies]
|
||||
base64 = "0.13.0"
|
||||
rand = "0.8"
|
||||
num-bigint = { version = "0.4", features = ["rand"] }
|
||||
byte_string = "1.0.0"
|
||||
num = "0.4.0"
|
||||
num-primes = "0.3.0"
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
prog :=pmc
|
||||
|
||||
debug ?=
|
||||
|
||||
$(info debug is $(debug))
|
||||
|
||||
ifdef debug
|
||||
release :=
|
||||
target :=debug
|
||||
extension :=debug
|
||||
else
|
||||
release :=--release
|
||||
target :=release
|
||||
extension :=
|
||||
endif
|
||||
|
||||
build:
|
||||
cargo build $(release)
|
||||
#strip -s ./target/release/$(prog)
|
||||
#strip --strip-unneeded -R .note -R .comment -R .gnu.version -R .note.ABI-tag ./target/release/$(prog)
|
||||
cp ./src/flag.txt ./target/release/
|
||||
cp ./src/p.txt ./target/release/
|
||||
cp ./src/q.txt ./target/release/
|
||||
|
||||
help:
|
||||
@echo "usage: make $(prog) [debug=1]"
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
## Cryptography challenge (Rust)
|
||||
|
||||
You are given the output of one cryptography system and the code that generates the output, the problem is we do not have access to the 3 files the code uses!
|
||||
|
||||
The first one is the flag.txt and the others are two files that have random prime numbers P and Q!
|
||||
|
||||
Can you help us decrypting the output and get the flag?
|
||||
|
||||
This challenge requires you to have cryptography and coding skills. Any language is accepted to get the solution. Please make sure to upload your solution through the form when you submit it.
|
||||
|
||||
_Keccak256: 0x42ce6fca873fe4dc4ce4d9accdb53e02fdb497ffa6b30f421cea36c81d8ea289_
|
||||
|
||||
_Challenge author: Rooney and Factoreal_
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
#!/usr/bin/env python3
|
||||
|
||||
from math import lcm
|
||||
from gensafeprime import *
|
||||
from Crypto.Util.number import *
|
||||
from flag import flag
|
||||
|
||||
def keygen(nbit):
|
||||
p, q = [generate(nbit) for _ in '01']
|
||||
n, e, phi = p * q, 65537, lcm(p - 1, q - 1)
|
||||
d = inverse(e, phi)
|
||||
return n, e, d
|
||||
|
||||
def encrypt(n, e, d, m):
|
||||
c1 = pow(n + 1, d >> 3, n ** 2)
|
||||
c2 = pow(m, e, n)
|
||||
return (c1, c2)
|
||||
|
||||
flag = bytes_to_long(flag)
|
||||
print (flag)
|
||||
n, e, d = keygen(512)
|
||||
c1, c2 = encrypt(n, e, d, flag)
|
||||
|
||||
print(f'n = {n}')
|
||||
print(f'c1 = {c1}')
|
||||
print(f'c2 = {c2}')
|
||||
|
||||
#validity = '[OK]' if (c1 - 1) % n == 0 else '[Not OK!]'
|
||||
#d3 = (c1 - 1) // n
|
||||
#....
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
n = 149611115935957861847433086030752568567261984621907082786040721407247152663716327519502231379009349403555478392331033952810164148573046688871056752042985601125672198741962270290757469688983708043363147130089304518146209920862956021757294842740478378766019286017585191433945507772906003202456007271670509560001
|
||||
c1 = 11740426501805700850493692315559578006370589284427206683940757663851146928230684257857117868496707849557168733347824952878380002709870656084949136086910227474133572170435190357845596727976524907841665784086757438386127200855803916010658428188870224409869769764930590879768926281176340935298646735957803036584600929550783080264478281164795674968941326608349176841871873099501077633763111936830560662765218747733834005879942262007725665002064520328109065794417151034621508526996605515243332144564900123239641752620534071998915306976614235709910119552618406674682923068789777245990088973508240448060554699343918041672
|
||||
c2 = 143776697087614888263290942500784196016072840323599778499088161935967819360208875932978673848883138508459204320371154339262196712020509264705583964011692527986711085787805336007197757175874259405887701369759903484733471121241423255620536627876637530300427365389368282535238625160577144155748657877913834928967
|
||||
|
|
@ -1,102 +0,0 @@
|
|||
use std::fs;
|
||||
extern crate num_bigint;
|
||||
extern crate rand;
|
||||
extern crate byte_string;
|
||||
extern crate num_primes;
|
||||
use num_bigint::{BigInt};
|
||||
//use num_primes::Generator;
|
||||
|
||||
extern crate num;
|
||||
use num::Integer;
|
||||
use num::One;
|
||||
use num::Zero;
|
||||
use std::convert::TryInto;
|
||||
|
||||
fn pow(n: BigInt, exp: BigInt) -> BigInt {
|
||||
n.pow(exp.try_into().expect("exponent too large for pow()"))
|
||||
}
|
||||
|
||||
fn modinv(n: &BigInt, p: &BigInt) -> BigInt {
|
||||
if p.is_one() { return BigInt::one() }
|
||||
|
||||
let (mut a, mut m, mut x, mut inv) = (n.clone(), p.clone(), BigInt::zero(), BigInt::one());
|
||||
|
||||
while a > BigInt::one() {
|
||||
let (div, rem) = a.div_rem(&m);
|
||||
inv -= div * &x;
|
||||
a = rem;
|
||||
std::mem::swap(&mut a, &mut m);
|
||||
std::mem::swap(&mut x, &mut inv);
|
||||
}
|
||||
|
||||
if inv < BigInt::zero() { inv += p }
|
||||
|
||||
inv
|
||||
}
|
||||
fn lcm(first: BigInt, second: BigInt) -> BigInt {
|
||||
&first * &second / gcd(first, second)
|
||||
}
|
||||
|
||||
fn gcd(first: BigInt, second: BigInt) -> BigInt {
|
||||
let mut max = first;
|
||||
let mut min = second;
|
||||
if min > max {
|
||||
let val = max;
|
||||
max = min;
|
||||
min = val;
|
||||
}
|
||||
|
||||
loop {
|
||||
let res = &max % &min;
|
||||
if res == BigInt::parse_bytes(b"0", 2).unwrap(){
|
||||
return min;
|
||||
}
|
||||
|
||||
max = min;
|
||||
min = res;
|
||||
}
|
||||
}
|
||||
|
||||
fn main() -> std::io::Result<()>{
|
||||
let contents = fs::read_to_string("./flag.txt")
|
||||
.expect("We lost the flag!");
|
||||
let contents = contents.to_string();
|
||||
let contents = contents.trim().to_string();
|
||||
let mut binary_flag = "".to_string();
|
||||
for character in contents.clone().bytes() {
|
||||
binary_flag += &format!("{0:08b}", character);
|
||||
}
|
||||
let flag_int = BigInt::parse_bytes(binary_flag.as_bytes(), 2).unwrap();
|
||||
// let p: BigInt = rng.sample(RandomBits::new(512));
|
||||
// let q: BigInt = rng.sample(RandomBits::new(512));
|
||||
let p_ = fs::read_to_string("./p.txt")
|
||||
.expect("We lost the p number! You can create p.txt with a large prime P");
|
||||
let p_ = p_.to_string();
|
||||
let p_ = p_.trim().to_string();
|
||||
let p = BigInt::parse_bytes(p_.as_bytes(), 10).unwrap();
|
||||
|
||||
let q_ = fs::read_to_string("./q.txt")
|
||||
.expect("We lost the q number! You can create q.txt with a large prime Q");
|
||||
let q_ = q_.to_string();
|
||||
let q_ = q_.trim().to_string();
|
||||
let q = BigInt::parse_bytes(q_.as_bytes(), 10).unwrap();
|
||||
|
||||
let n: BigInt = &p * &q;
|
||||
println!("n = {}", &n);
|
||||
let one: BigInt = BigInt::parse_bytes(b"1", 2).unwrap();
|
||||
let one_: BigInt = BigInt::parse_bytes(b"1", 2).unwrap();
|
||||
|
||||
let e: BigInt = BigInt::parse_bytes(b"65537", 10).unwrap();
|
||||
let phi = lcm(&p - &one, &q - &one);
|
||||
let d: BigInt = modinv(&e, &phi);
|
||||
let n_1: BigInt = &n + one;
|
||||
let eight: BigInt = BigInt::parse_bytes(b"1000", 2).unwrap();
|
||||
let pow_n_2: BigInt = &n * &n;
|
||||
let d_8: BigInt = &d /&eight;
|
||||
let c1: BigInt = n_1.modpow(&d_8, &pow_n_2);
|
||||
let c2: BigInt = flag_int.modpow(&e, &n);
|
||||
println!("c1 = {}", &c1);
|
||||
println!("c2 = {}", &c2);
|
||||
|
||||
Ok(())
|
||||
}
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
## Cryptography challenge (Rust)
|
||||
|
||||
TBA
|
||||
|
||||
_Keccak256:
|
||||
|
||||
_Challenge author:
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
## Fibonacci WSS challenge
|
||||
|
||||
Connect to the WSS service and solve the challenge presented: 45.77.137.182:3333
|
||||
Connect to the WSS service and solve the challenge presented:
|
||||
|
||||
This challenge requires you to have basic problem solving and coding skills. Any language is accepted for get the solution. Please make sure to upload your solution through the form when you submit it.
|
||||
|
||||
You need to send the sequence one by one.
|
||||
|
||||
_Keccak256: 0x2f2d4bb11521956c486925241ffcca0cbf7b79bbd9be8eafaeb4fab95713b12d_
|
||||
_Keccak256:
|
||||
|
||||
_Challenge author: Natoshi Sakamoto_
|
||||
Loading…
Reference in New Issue