This is the second part of compiler which will receive token from lexical analysis. If you are still not familiar with lexical analysis, here is the door. The goal of parsing Receive sequence of tokens from lexer and output parse tree of the program. Given a very clear example from the course, 1 2 3 4 5 6 7 8 9 if x == y then 1 else 2 # parser input (given by lexer) IF ID == ID THEN INT ELSE INT # parser output IF-THEN-ELSE / | \ / INT INT < > ID ID To summarize,

ROP attack

Return-Oriented-Programming is a basic attack on memory-safety vulnerabilities. If we can arbitrarily overwrite the return address, then we can hijack the control flow. In this article, I would like to introduce a series of ROP attack with practical example in CTF challenges. The following link in each section would be directed to my repository in github. In here, our first goal is always to call shell. Basic ROP Start your first ROP here ret2plt return 2 plt We don’t need to build up the whole chain by instructions.

Say farewell to pointer's challenge

Pointer is one of the most confusing and challenging concepts in C/C++. It is also an important concept in binary analysis and software development; therefore, this article is to say farewell to my difficulty of understanding pointers. Intro to pointers 1 2 3 type* ptr; // this way is more recommended because type* means type of pointer type * ptr; type *ptr; We always can see these three types of pointer declaration in code.


身為一個一年級PhD學生,又沒有論文發表的經驗,總是對自己對於conference的無知覺得驚慌。這篇文章就來記錄一下對這種會議的了解,也會持續更新各種會議!其中可能是從一些大牛reviewer的文章中學到的,想參考原文可以到reference中翻找! ICSE Review ICSE身為Software Engineering領域的頂級會議,總是有著超過600篇的提交數。論文作者必須標明跟他們論文相關的領域,而reviewer也是方便讓他們自己找match的paper去審核。 對reviewer而言,ICSE會給出數個deadline,e.g. 50%,70%,100%review 進度的deadline,而且如果錯過其中任何一個deadline可能就喪失reviewer的資格了。除此之外,ICSE的review form包含更多的細節,對於rejection也要求很完善的feedback。從這裡可以得知,就算被ICSE拒了,也能得到很多建議!@Andreas Zeller[1]對於co-reviewer的描述就是感覺像是抓論文bug的官僚系統。 在accept前當然就是reviewer之間的fighting囉(just kidding)。PLDI和ICSE都要至少有一個reviewer給出最高評分才能進入是否accept的討論。@Andreas Zeller[1]覺得在這個討論的過程中,大家都比較不願意切換他們的視角。ICSE在接受你的paper之後,就代表commitee認為你的paper沒有什麼毛病了,可以去放假囉! 論文的趨勢 大部分論文都會提出新的testing或analysis技巧,而且還會附上完善的implementation以及evaluation。Implementation很重要,甚至在2022年,附上data會變成必要的選項。 PLDI Review PLDI是有關於programming language的頂會,他們會使用一個Toronto paper matching system,透過語意分析去找跟reviewer領域相近的paper,當然reviewer還是可以自己決定要審核哪些論文! 對reviwer而言,雖然過程跟ICSE很像,但是PLDI更講究對reviewer的信任。@Andreas Zeller[1]也有提到,整個review過程包含與許多相同領域的學者討論與合作,所以他推薦如果有機會收到PLDI reviewing的邀請,一定要去!他對於co-reviewer的描述就是感覺大家都很願意去深入理解論文裡面描述的每一個細節! @Andreas Zeller[1]覺得PLDI在這個討論是否accept的過程比較特殊的是,每個reviewer都很願意切換自己的視角,不會一直那麼高姿態。PLDI是著名的conditional accept,意思就是就算paper已經被accepted,reviewer還是會跟你合作修改paper直到可以被完美得公開。 論文的趨勢 越來越多論文喜歡做跟semantics相關的研究,當然PLDI非常非常重視implementation,畢竟PLDI的I就是指implementation嘛,所以Andreas也說他可能可以一天讀兩篇ICSE或者CCS的論文,但一定會花至少一天讀單篇PLDI的論文! CCS Review CCS則是Security領域的四大頂會,會有列出track讓reviwer自己去選擇想要審核的論文。@Andreas Zeller[1]提到他對於CCS的經驗就是大家對deadline都不太重視。他感覺到reviewers不太互相重視,甚至也沒有很重視researchers。他對於co-reviewer的描述就是感覺大家很能夠精準得辨認一篇論文技術觀念的優點和缺點,但對於寫壞(描述艱澀難懂)的論文,他們就會很容易失去耐心!對於CCS討論是否要accept論文的過程,Andreas覺得一樣是late的問題,很多作者都太晚收到feedback了,甚至連decision summary(accept or reject)在討論結束之後一個禮拜都還沒送出! 論文的趨勢 @Andreas覺得近期security方面的論文有點流於在用找到vulnerabilities的多寡數在證明自己的觀念是否正確。但其實去證明自己的觀念為什麼正確比起找到漏洞的數量更加正確。像是在PLDI和ICSE裡,reviewer都會詢問benchmark是怎麼挑選的?ground truth是怎麼蒐集的?@Andreas擅長於fuzzing的部分,然而在他審核的論文中沒有一篇提到這幾個點。 Reference How do different fields review papers? Experiences from ICSE, PLDI, and CCS


開發日常 想要開發自己的pass,可以加入main file和對應的header file在/src/pass裡面,在把選項放在etharden或etshell裡面。Compile就只要在/app資料夾裡面下make就好,他就會進行部分編譯和連結。 這裡記錄一些常見到的function: recurse()可以在dump.h裡面找到: 1 2 3 4 5 void recurse(Type *root) { for(auto child : root->getChildren()->genericIterable()) { child->accept(this); } } 可以知道這個函式會用來往下訪問所有的children… accept()可以提供各種類型chunk的遍歷方式: 1 2 3 4 5 6 7 8 9 10 11 12 void Chunk::accept(ChunkVisitor *visitor) { visitor->visit(this); } ...then traverse... virtual void visit(Program *program) {} virtual void visit(Module *module); virtual void visit(FunctionList *functionList); ... virtual void visit(Function *function); virtual void visit(Block *block); virtual void visit(Instruction *instruction); .

Precisely Characterizing Security Impact in a Flood of Patches via Symbolic Rule Comparison

I enjoy reading this paper. This paper makes everything very clear, and makes announcement about the definition again and again. It mentions his source code in the paper; however, without the open source code. Hope it can release the open repository in the future, it can persuade me more about its effectiveness. Introduction and Background For software vendors and maintainers, they always can get many reports from users about the bugs.