まわ

勉強したことや遊びのこと

RSA暗号解読問題を解く(後編)[CTF for Beginners 2018]"RSA is Power"

f:id:k_mawa:20180619141331p:plain

経緯

これの続き。

k-mawa.hateblo.jp

ちょっとだけ巻き戻しで、まず問題に与えられている数字は以下

N = 97139961312384239075080721131188244842051515305572003521287545456189235939577
E = 65537
C = 77361455127455996572404451221401510145575776233122006907198858022042920987316

前回、素因数分解パッケージのmsieveの計算パワーで、素因数のペアが、299681192390656691733849646142066664329と324144336644773773047359441106332937713になるということころまでわかりました。

さてその続き。

pycryptoを使う

インストールが必要

$ pip install pycrypto

これでよし。

さて計算。まずわかっている数を書く。

N = 97139961312384239075080721131188244842051515305572003521287545456189235939577
E = 65537
C = 77361455127455996572404451221401510145575776233122006907198858022042920987316
p = 299681192390656691733849646142066664329
q = 324144336644773773047359441106332937713

公開鍵から秘密鍵をつくる

#pycryptoをインポート
from Crypto.PublicKey import RSA
from Crypto import Random
from Crypto.Util.number import * #inverse()を使う
import Crypto.PublicKey.RSA as RSA

>>> inverse(E,(p-1)*(q-1))
88509020092584531671107468782943602124921999287671161687233461555074737950465

d = inverse(E,(p-1)*(q-1))

>>> d
88509020092584531671107468782943602124921999287671161687233461555074737950465

#秘密鍵
  • pycryptoのinverse()について
inverse()
秘密鍵 = inverse([公開鍵にする数], [(p - 1) * (q - 1)])

inverseが何をしているかはこれを。 https://asecuritysite.com/encryption/inve?val1=17&val2=3120

秘密鍵で暗号化された文章を復号

rsa_key = RSA.construct((p*q, E, d))
#もちろんrsa_key = RSA.construct((N, E, d))でもOK

>>> rsa_key
<_RSAobj @0x10f7b06a0 n(256),e,d,p,q,u,private>

>>> rsa_key.decrypt(C)
175721217420599820463601725034319415104774797848891230924248444157707646333

int = rsa_key.decrypt(C)

>>> long_to_bytes(int)
b'ctf4b{5imple_rs4_1s_3asy_f0r_u}'

解けた!!

  • pycryptoのRSA.construct()について
RSA.construct
RSA = RSA.construct(([モジュラとする数],[公開鍵にする数],[秘密鍵にする数]))

参考記事

SECCON Beginners CTF 2018 Write-up

zeosutt.hatenablog.com

Django-Celery-Redisのherokuへのデプロイメモ。

Heroku: Up and Running

Heroku: Up and Running

  • 作者: Neil Middleton,Richard Schneeman
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2013/11/24
  • メディア: ペーパーバック
  • クリック: 2回
  • この商品を含むブログを見る

コメント

Django+Celeryで非同期処理ができるようになり、最終関門はherokuデプロイです。情報が少ないし公式ドキュメントだけだと(たぶん)エラーになり・・・ついにできました!その時のメモ。

手順1 Procfileに追加→Redis動かすワーカー起動を指示

Procfile

web: gunicorn [プロジェクト名].wsgi:application -b 0.0.0.0:$PORT
worker: celery worker -A [プロジェクト名].celery -l INFO
#↑この行が追加された
#ローカルで必要だった、$celery -A [プロジェクト名] worker -l infoをherokuが勝手にやってくれるイメージです

手順2 heroku localで動くか動作確認

(どこでもOK)$redis-server #redis起動は同じく必要
(仮想環境)$heroku local

ここまではローカルのsettings.pyで動かしました。これでデプロイ下準備は完了。

手順3 heroku-redisアドオンを追加

$heroku addons:create heroku-redis:hobby-dev

elements.heroku.com

手順4 アドオンが追加されたか確認

$ heroku redis:info
=== redis-xxxx-123456 (REDIS_URL) #仮の名前に変更してます
Plan:               Hobby Dev
Status:             available
Created:            2018-06-15 13:19 UTC
Version:            3.2.11
Timeout:            300
Maxmemory:          noeviction
Maintenance:        not required
Maintenance window: Thursdays 17:30 to 21:30 UTC
Persistence:        None
HA Status:          Unavailable

これはwebのherokuコンソールでも確認可能です。

手順5 Django用のheroku-redis接続パッケージをインストール

django-redis-cacheというモジュールが必要。公式ページに記載されてました。

pip install django-redis-cache

pip freeze > requirements.txt

手順6 settings.pyのCelery設定をデプロイ先のheroku-redisに接続されるようにする

#settings.pyローカルで動いた参考例(引用です)

BROKER_URL = 'redis://localhost'
CELERY_RESULT_BACKEND = 'redis'
CELERY_TASK_SERIALIZER = 'json'
CELERY_RESULT_SERIALIZER = 'json'
CELERY_ACCEPT_CONTENT = ['json']

引用元

Celery 3.1 を Django で使う

↓こう変える

#↓ここから追記↓

import os

CACHES = {
    "default": {
         "BACKEND": "redis_cache.RedisCache",
         "LOCATION": os.environ.get('REDIS_URL'),
    }
}

BROKER_URL = os.environ.get("REDIS_URL")
CELERY_RESULT_BACKEND = os.environ.get("REDIS_URL")

#↑ここまでが変更点↑

#BROKER_URL = 'redis://localhost' #localのときだけ
#CELERY_RESULT_BACKEND = 'redis' #localのときだけ
CELERY_TASK_SERIALIZER = 'json'
CELERY_RESULT_SERIALIZER = 'json'
CELERY_ACCEPT_CONTENT = ['json']

REDIS_URLという環境変数はheroku:redisを導入しときに勝手に設定されるのです。

手順7 いつものようにherokuにデプロイ

$git add.
$git commit -m "celery"
$git push heroku master

手順8 logをとってうまく行ってるかチェック

$heroku logs -t

参考資料

"Connecting in Django"の箇所 devcenter.heroku.com

自分の完成形とちょっと違うけど、参考になりました github.com

DjangoからCeleryへのタスクがつながらず、サーバーがずーっと応答しない!ときのCeleryセッティングのチェック項目

コメント

Celery(セロリ)が動きそうで動かないことがあります。djangoローカルサーバーがviewを呼び出したまま止まるのでエラーも吐かないのでなにをしてるかよくわかりませんでした。チュートリアル記事も何度も見直したのに動かない・・・こないだは動いたのに・・・なぜだ・・・これを次回から回避できます。

チェック項目

  • その1:pip install celeryは済んでいる

  • その2:pip install redisは済んでいる

  • その3:settings.pyにBROER_URLなどの記載は済んでいる

#settings.py参考例(引用です)

BROKER_URL = 'redis://localhost'
CELERY_RESULT_BACKEND = 'redis'
CELERY_TASK_SERIALIZER = 'json'
CELERY_RESULT_SERIALIZER = 'json'
CELERY_ACCEPT_CONTENT = ['json']

引用元

Celery 3.1 を Django で使う

  • その4:settings.pyがあるディレクトリの__init__.pyceleryに必要なコードを追記してある(今回はこれが抜けてた!追記すると動いた^^;)
#__init__.py

from __future__ import absolute_import, unicode_literals
from .celery import app as celery_app

__all__ = ['celery_app']
  • その5:task.pyに非同期処理する関数を@shared_taskデコレータつきで書いてる

  • その6:settings.pyがあるディレクトリのcelery.pyの追加と書き込みは済んでいる

  • その7:$brew install redisは済んでいる

  • その8:$redis-serverは動いている

  • その9:$celery -A [proj名] worker -l infoでワーカーは動いている

その8とその9あたりは、下記を参照ください

k-mawa.hateblo.jp

と、いうわけでおおまかに書いても9個もチェック項目があるという・・・

vue.jsを触ってみた。it worksまで

f:id:k_mawa:20180617021558p:plain

経緯など

↑の本。うちのフロントエンドはvue.jsでできているサービスが一個あり、担当の同僚いわく、AngularとReactと比べてオススメということで、話を聞いていたのですが、TwitterTLでもvue.jsの話がたくさんでてくるような気がしたので、なんとなくvue.jsの最初だけやってみたのです。

あと、モバイルアプリ開発でvue nativeというのも出たという話も聞いたので、いよいよswift, kotolin, javaはモバイル開発のためにまたさらに個別に複数言語と環境構築からデプロイまでを学ばなくていいかも!?という期待もあり・・・苦笑 ( Unityで頑張ってコード書いてきたC#でできるXamarineがよりヒットしてきてくれないかなって期待もあるんですが・・・ )

と、いうわけでit worksまでやりました。

まず環境構築node.js&npm

とりあえず、ランタイムのnode.jsを入れる。パッケージ管理(のほかに色々できるっぽい)ツールnpmも入れる。

qiita.com

node.js インストール時に、このエラーありました。

curl: (23) Failed writing body (0 != 941)

この記事のおかげで解決 qiita.com

テストプロジェクトを開発サーバーで起動(?)

ってことかな??とりあえず動きました。

$npm i vue
$npm i -g vue-cli
$vue init webpack my-proj

#このコマンド後色々質問がくるけど適当に答えた

$cd my-proj
$npm run dev

#128.0.0.1:8081に開発サーバーが公開してくれてる

こんな感じ! f:id:k_mawa:20180617021558p:plain

参考になった書籍

React、Angular、Vue.js、React Nativeを使って学ぶ はじめてのフロントエンド開発

React、Angular、Vue.js、React Nativeを使って学ぶ はじめてのフロントエンド開発

コード署名のメモ。brew install gdbだけでは動かないよという話

Advanced Apple Debugging & Reverse Engineering Second Edition: Exploring Apple Code Through Lldb, Python and Dtrace

Advanced Apple Debugging & Reverse Engineering Second Edition: Exploring Apple Code Through Lldb, Python and Dtrace

コード署名が必要なパッケージがあると知る

gdbというデバッガーをMacOSで使おうとした時、brew install gdbではいることははいるけども、$gdb コマンドを打っても起動しない。これは、コード署名という手続きが必要なパッケージだったのだ・・・(これは上手く行ったが、他のサポートの問題で結局gdbじゃなくてlldbというのを使うことになったのだが・・・)

その顛末の続きはこちら k-mawa.hateblo.jp

で、コード署名というのをやってみたので、今後コード署名という手続きが必要なパッケージがあるかもしれないので、メモしておく。

詳しくはここにかいてある qiita.com

のでここでは手続きのメモを。

1:MacOSのキーチェーンアクセスを開く
$open -a "Keychain Access.app"
↓
2:GUI操作でコード署名するという意味合いの証明書をつくる
↓
3:システム配下に設置(エラーがでるときはログイン配下に設置してからシステム配下にドラッグアンドドロップで移動)
↓
4:つくった証明書を「常に信頼する」に変更(GUI)
↓
5:システムのフォルダにかかっている鍵をあける。じゃないとコマンド打っても鍵が見つからないって出る(GUI)
↓
6:コード署名コマンド実行
例)$ sudo codesign -s gdbcert /usr/local/bin/gdb
#gdbcertは自分で決めた証明書の名前
#コマンド応答はないけど、鍵の音がなって完了した

これで、動くようになる(gdbはOSサポートの影響?という別の要因で完璧には動かなかったけど、コード署名はうまくいって起動はできるようになった。)

デバッガーgdbとlldbとMacOSについてのメモ

Advanced Apple Debugging & Reverse Engineering Second Edition: Exploring Apple Code Through Lldb, Python and Dtrace

Advanced Apple Debugging & Reverse Engineering Second Edition: Exploring Apple Code Through Lldb, Python and Dtrace

gdbとlldbというもの

CTFではよく使われるっぽいデバッガーでgbdというものがある、それで、いろいろインストールしたのだけども、どうしても動かない

エラー

(gdb) run
Starting program: /Users/hoge/Desktop/fuga/test 
During startup program terminated with signal ?, Unknown signal.

最終的にはこのあたりに行き着き・・・gdbのダウングレードをしてみたけどもやっぱり同じエラー stackoverflow.com

で、どうやら、MacOSX High Serraはgdbサポート外らしい。↓ [C] デバッガgdbを使用しているときに不明な終了信号 macos | CODE Q&A [日本語]

え〜うーむそうしたらどうするの・・・

lldbというものがあるらしい!

代替物が発見された・・・しかもMacは初期設定時に入ってるとのことで・・・

qiita.com

$ lldb test
(lldb) target create "test"
Current executable set to 'test' (x86_64).
(lldb) run
Process 2367 launched: '/Users/hoge/Desktop/fuga/test' (x86_64)
test #予定していた出力printf
Process 2367 exited with status = 0 (0x00000000) 
(lldb) 

機能してるぅ!よかった一安心。

Django:social-auth-app-djangoとUUIDフィールドで苦労した話

Anthology

Anthology

コメント

最初にDjangoで運営してるメディアで、TwitterのSocialAuthでいきなりエラーがでてログインできなくなったんですよ!いままでは問題なく動いてたのに!!これが起きてしまったPYPIパッケージはsocial-auth-app-django==2.1.0でしたご注意を!!

HTTPError: 403 Client Error: Forbidden for url: https://api.twitter.com/oauth/request_token

ほっといても直らないし、APIの制限にひっかかることもしてない(Twitterデベロッパー管理画面でチェックしてもなにも制限されてる旨の表示はなし。キーを一回再生成したけど意味なし)らちがあかないので、もうメール認証でユーザーログイン機能を実装しなおそうと思い始めました。

経緯

#usermanage/models.py

class User(AbstractBaseUser, PermissionsMixin):

    uuid = models.UUIDField(default=uuid_lib.uuid4, primary_key=True, editable=False)
    #↑idのかわりにuuidを使ってみている

そうすると、ユーザー新規登録時にエラーがでてしまう。

・・・(中略)・・・
UUID('<uuidの文字列>') is not JSON serializable

なんだこれは・・・Oauthでは出なかったのにぃ・・・と、ググると、Django1.7以前あたりは有名なバグだったらしいが、今はDjango2.0だし、解決されてるよかったね的な公式記事が・・・うーむ。

https://code.djangoproject.com/ticket/24320

一旦諦めてuuidをやめようとするが・・・

うーん。でもuuidをPrimaryKeyにしちゃってるし、今からIDフィールド別途作ってとか・・・危険な感じしかしない・・・と、いうわけで多少安全そう??な(誤解)UUIDフィールドをPrimaryKeyのままCharfieldにしちゃうとシリアライザ−エラーが直ってハッピーなのでは??と仮説を立てる。で、実行。ついでにuuidの文字列がなにかリスクがあるのかもしれないと、数字だけで小さいメディアだし、かぶりにくいだろうタイムスタンプの羅列でチャレンジ。こういう感じ

uuid = models.CharField(max_length=500, default=datetime.datetime.now().strftime("%Y%m%d%H%M%S%f"),
                            primary_key=True, editable=False)

ローカルslqliteでは無事マイグレーションもできて動く!OK!いい感じだ。

で、herokuにデプロイ。migrat...エラーあああ!!!

DETAIL:  Key columns "user_id" and "uuid" are of incompatible types: uuid and character varying.

うーむ。調べるとPostgreではなんかフィールドをUUIDから変えようとするとなる症状らしいっぽい。。。

UUIDのままだと、最初のエラーがでるし、奇策のCharfield作戦は、Postgreに阻まれる。おいおいプロジェクト作り直し??絶望・・・

しかし諦めずに調べると、神記事が現れた!

arthurpemberton.com

これ!!!しかもうまくいきますようにみたいなお祈りも書いてる、、、良い人だ〜〜^^/

#usermanage/models.py に追記する↓

#↓ここから追記開始↓
from json import JSONEncoder
from uuid import UUID

JSONEncoder_olddefault = JSONEncoder.default

def JSONEncoder_newdefault(self, o):
    if isinstance(o, UUID): return str(o)
    return JSONEncoder_olddefault(self, o)

JSONEncoder.default = JSONEncoder_newdefault
#↑追記はここまで↑

class User(AbstractBaseUser, PermissionsMixin):

    uuid = models.UUIDField(default=uuid_lib.uuid4, primary_key=True, editable=False)
    #下記、モデルの続きが書いてある

すると、エラーが消えた!!!ありがとう〜〜〜m( )m